Software Configuration Management
Use "a" key to toggle between single page and slideshow modes.
Use the space bar or right arrow for next slide,
left arrow to back up.
What comprises a software product?
A set of files, containing:
- Implementation code
- Tests
- Scripts to build software, run tests, build distributions
- Documentation, training materials
- Data files, databases, database schemas
- Tools & Components (compiler, libraries, linker, database manager, etc.)
All of these evolve through multiple versions.
Definition according to Wiki
Configuration management is the management of features and
assurances through control of changes made to hardware, software,
firmware, documentation, test, test fixtures and test
documentation of an system, throughout the development and
operational life of a system.
Source Code Management or Software Configuration
Management (both "SCM") is part of this.
Definition according to Dennis et al.
Configuration and change management is the tracking of
the state of the artifacts (hardware, software, firmware,
documentation, tests, test fixtures, and test documentation)
throughout the development and operational lifetime of a
system.
Software Configuration Management
- Approximate synonyms:
- Revision control
- Version control
- Source control
- Source code management
- Related concepts:
- Work flow
- Work queues, task tracking
- Web content management
What is the problem?
What is the problem?
- The product is comprised of multiple files
- Each goes through various changes (versions)
- Only certain combinations of items work together
- Need to keep track of what works with what
Scenario
- Joe and George are working on a project together
- Joe modifies module M to fix a bug, adding a variable X.
- George is adding a new feature, and also adds a variable X to module M.
- Each debugs his code, separately.
- Now they want to merge their changes into a workable version of the system.
- How is this done? What do they do about the conflicting uses of M.X?
Scenario
- Joe is working on a project together with other people.
- Joe runs a test that passed last night, but now it fails.
- Joe did not make any changes to the (shared) code.
- Who made the change that broke the test, and what was it?
Scenario
- Release 1 of the Apogee software has been moderately successful, and the A-team
is working on Release 2, which will include several new features.
- Customers report some critical security flaws in Release 1. The company needs to
fix them, or customers will be angry. They can't wait to fix the bugs in Release 2,
and even if they could they do not want to give away Release 2 for free to customers who have only
paid for Release 1.
- The B-team is assigned to fix the bugs in Release 1, and issue a bug-fix Release 1.1.
Where do they get what they need to generate Release 1.1?
- Later, the A-team will issue Release 2 of Apogee.
How to they make certain the bugs fixed in Release 1.1 do not appear in Release 2?
Scenario
- Release 1 of the Apogee software has been released for MS Windows Vista, and is moderately
successful.
- The company wants to also release a version for Linux. This will require changes to some of the
code modules, but most of the code will be the same.
- How does the company manage these two versions of the product, in a way that maintains the
difference between the Windows Vista and the Linux versions, but ensures that bug-fixes and
enhancements are made in parallel to both versions?
What artifacts make up a system configuration?
- Hardware - ANY hardware that is used by the system.
- Software - system software (OS, DB, Compiler, etc), supporting software (sorters, mergers, utilities), application software (you wrote or you use).
- Firmware - ANY firmware used by the system.
- Documentation - deliverables for development, documentation maintained for the operation of the system, etc.
What is a software configuration?
- A collection of versions of files and directories
- That logically belong together
- because they are being tested together (a development configuration)
- or because they are to be delivered together (a release)
|
|
SCM Goals
- Manage the changes to documents, programs, files, etc.
- Identify and maintain configurations (compatible versions of a set of items)
- Track history of changes
- Identify person responsible for each change, and reasons
- Be able to recover (roll back to) previous configurations
Complicating Factors
- Multiple authors
- Working concurrently
- Possibly geographically distributed
- Need to maintain multiple branches (e.g., development branches, bug fixes on old releases)
- Must be robust against disk crashes, human errors
SCM Tools
- Help identify and track configurations
- Vary from simple to complex
- Vary in cost from $0 to $400,000
- Vary in certain structural aspects
A revision control (also called "version control") tool allows
you to track revisions to both files and collections of file
versions (configurations), obtain copies of past versions at any
point, and roll back to older versions if you desire.
There are many different revision control tools, of both commercial and
open source varieties. Integrated development environments typically will
include a revision control system. You can also use revision control tools
in a stand-alone fashion.
SCM Tool Capabilities
Track files, or entire configurations
- Share code between developers
- Maintain history of changes
- See what changed between one version and another
- Identify who made changes between versions, and why
- Fetch a copy, or roll back to any prior version
- Maintain multiple branches
- Merge branches
Three Ways of Handling Concurrent Updates
- Atomic commit operations (transactions)
- File locking
- Version merging
Some Core SCM Concepts
- File vs. configuration
- Version/revision numbers
- Timestamps
- Releases
- Repository
- Working copy, or "sandbox"
- Baseline/Trunk/Mainline
- Branches/Forks
- Change list, or patch
|  |
More Terms & Concepts
- "Checkout" has multiple meanings
- Get local working copy, or just make it visible?
- Locked, not?
- Entire configuration, or just one file?
- Export/Import
- Commit
- Conflict (superficial, vs. deep)
- Merge
- Tag = attached to files represents a snapshot in time (a configuration)
Centralized SCM (svn)
|
Operations require a server
- single point of failure
- bottleneck
Simpler to use
|
Decentralized SCM (git)
|
Anyone can be a server
More versatile
More ways to get confused & shoot foot
|
Examples of SCM Tools
- rcs - the grandmother of Unix SCM tools,
for local use on a system, by a single user or members of a group.
- cvs - a layer over rcs that provides additional functionality
for remote access to a server that can be shared among members of a group.
Support for CVS is built into the
Eclipse IDE
- svn - Subversion, a newer and fuller-featured
system, used by SourceForge and Google Code, among many other groups.
Probably the most dominant current tool.
Support for SVN is also available in the
Eclipse IDE
- git - is used by the Linux kernel development community. It
differs from the above in being based on a decentralized
distributed model.
- mercurial (hg)
- bazaar (bzr)
- ... and many more
Git Repository
Contains
- files
- commits
- ancestry relationships
|
|
The nodes in the DAG are configurations, not files.
How Decentralized (git) SCM Works
|
|
Anyone can be a server
|
How Decentralized (git) SCM Works
|
Start with a global repository
|
How Decentralized (git) SCM Works
|
Make a local copy by cloning it
|
How Decentralized (git) SCM Works
|
Cheap local clones can be made via links
|
How Decentralized (git) SCM Works
|
Changes can be pushed back upstream
|
How Decentralized (git) SCM Works
|
You can publish to a Web server
|
How Decentralized (git) SCM Works
|
Or you can share with trusted peers
|
An Agile Workflow for Git (or Svn)
|
All developers are equal.
All pushed changes to same repository.
Repository is always up to date with the current "wave front".
|
See Pro Git at http://progit.org.
UML Sequence Diagram for this Workflow
A Git Branching Workflow Model
|
Distinguishes feature, development, release, hotfix, and master branches
|
See nvie.com.
A Managed Repository Model
|
Only one person can push changes to the blessed repository.
Means less chance of accidents, but we now have a bottlneck.
|
See Pro Git at http://progit.org.
Android Git Workflow Model
|
Two kinds of review, verification by multiple testers before admission to repository.
|
See source.android.com.
"Story branch" pattern with git
- Choose a feature/task/story to work on, and mark it as being worked on (presumes a workflow tool is being used)
- Git a fresh copy of the baseline code tree
git checkout master
git pull
- Make a branch to work in
git checkout -b storybranch
- Write a test for the feature/story
- Make changes to the code, commiting often
git commit -am "summary of what changes I made just now"
- When the test passes, do another commit, and cycle back to step 4,
until the feature/story is believed to be complete
- Merge with master
- Review changes
git diff master
- Merge changes
git checkout master
git pull
git checkout storybranch
git rebase master
Do this frequently, to keep in sync. with other changes.
- Correct any conflicts, and repeat until convergence
- Push new version back to the trunk
git checkout master
git merge storybranch
git push
git checkout storybranch
This presumes there are no merge conflicts.
Combined from
Agile git and the story branch pattern and
Hack && Ship
Notes:
- Some teams add a moderator, to check that changes to the master branch
are OK, before everybody else sees them.
- Using
git rebase -i ... permits "squashing" multiple
intermediate revisions, to make history more readable.
CM Standards
- IEEE Std. 828-1998 IEEE Standard for Software Configuration Management Plans
- ANSI/EIA-649-1998 National Consensus Standard for Configuration Management
- MIL-STD-973 Military Standard for Configuration Management[1] (cancelled, but still good reference)
- GEIA Standard 836-2002 Configuration Management Data Exchange and Interoperability
