Software Configuration Management
Steven J Zeil
Over time, a software system can exist in many versions:
- revisions created as developers check in changes
- configurations intended for different hardware, operating system, or application environments
- releases issued to users
- which, if under continued support, may have separate tracks of revisions recording separate bug fixes
Software Configuration Management (SCM) is concerned with all of these.
Some of the tools we have already looked at (build management, version control) can help. But in SCM we need to look at the strategic application of those to the management of many different software versions.
1 Problems Addressed by SCM
The last two are new.
The first two we have discussed in isolation.
- But the broader SCM context may alter how we use some of them
1.1 Codelines and Baselines
A codeline is a sequence of revisions of a configuration item
In essence, a branch
A baseline is a collection of component versions that make up a system.
1.1.1 Codelines and Baselines: Example
A baseline merges components that we have written (a version out of our codelines) with versions of 3rd party components that we employ.
A major challenge of SCM is coping with multiple baselines that must
- co-exist and
- be actively maintained.
Major issues are
- deciding when to “freeze” on a version of an imported library
- tracking the transitive closure of dependencies from libraries that we directly depend upon
- finding a mutually compatible set of versions among all those external libraries
2 Environment Management
Coping with the different environments in which the software may need to be installed and/or built.
- Strategies include
- separate files
- Easier to manage in the C/C++ world than in Java
- deltas (patches)
- conditional compilation
- Favored in the C/C++ world
- Harder to support in Java world
- dynamic loading
- Common in the Java world
- Often controlled by “property files” that name modules to be employed for designated tasks in a given installation.
- separate files
Example: the ODU Extract Project
Metadata extraction system, needed to support
One release version (thank the heavens)
Windows, Linux, & Mac platforms
Choice of 2 OCR programs (or none at all)
- With local or network access to licensed copies
- With or without caching of OCR results
Statistical models trained on different document collections
Varying client requirements for data post-processing
Problem was not so much the number of choices as the combinatorics.
Third Party Libraries
Baselines may involve multiple 3rd-party libraries.
- Different baselines may need different libraries.
- Or different versions of the same library
Luckily, there’s automated support for this aspect of SCM, which we will cover separately.
3 Build Management as an SCM Activity
In an SCM context, we may have multiple baselines.
The build manager needs to be flexible enough to allow us to build each of those on command.
In some cases, using remote machines or virtual machines, to build all of them on (one) command.
3.1 Baselines Managed by Build Manager
Build manager is told what external libraries are needed
- including desired versions
- This is easier to do once we get a handle on 3rd party library management.
Build manager may be responsible for collecting desired versions of both external and internal code from version control.
Build files are themselves managed as part of each version.
3.2 Simpler Project Structure
In current practice,
Large projects composed of multiple subprojects are discouraged
in favor of smaller, independent projects (e.g., one per original subproject)
A common rule of thumb is that one project should produce one product (e.g., a single Jar file)
Plus, perhaps, a source distribution.
- and those are increasingly being replaced by centralized VC repositories
4 Version Control as an SCM Activity
We’ve spent time looking at version control already.
We have lots of flexibility in terms of
- Access to the version history
- Distributed vs central access.
SCM challenges us to think strategically about how to exploit that flexibility.
4.1 Codelines == Branches
Main trunk moves forward in time
Each planned release is a branch from the trunk
- continues forward through its maintenance lifetime
5 Change Management
- When do proposed changes become an official part of a version?
- When do changes propogate multiple versions?
5.1 Making Decisions
In large organizations, changes are approved by a Change Management Board.
E.g., the team working in an exploratory branch has demonstrated an attractive new feature.
- Should we adopt it?
- If so, which of the version code lines should it be added to?
5.2 Change Propagation
Even in smaller projects, the issue of change propagation across code lines needs to be kept in mind.
- The whole “main trunk moves forward” idea presumes that most release changes are synced into the trunk:
- As a practical matter, someone has to decide whether bug fixes in older versions can and should be merged into later versions.