Software Configuration Management
Steven J Zeil
Abstract
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
-
SCM Activities
-
Version control
-
Build management
-
Environment management
-
Change management
-
-
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.
1.1.2 Baselines
-
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
- Branches
- 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.
5.3 Merge Requests
Open source projects often have a structure of
- Core developers who manage the overall vision and quality of the project over an extended period of time.
- Contributors who are loosely affiliated with the project and may only particpate for limited periods of time.
Typically, the main release branches can only be modified by the core developers.
5.3.1 Everybody has their own branches
Remember that, in the git
distributed model,
- Every developer gets their own copy of the repository…
- …with their own set of branches that are
-
distinct from, but
-
“synced” with
the central branches.
-
5.3.2 Contributors…
- Create their own branch from one of the release branches.
- This is more or less automatic in
git
anyway.
- This is more or less automatic in
- Edit the code to add a feature of fix a bug.
- Commit their changes in their branch.
- Send a “merge request” to the core developers identifying the branch containing their work and indicating the issue they were working on.
5.3.3 Core developers…
- Accept the merge request.
- Check out their own copy of the relevant release branch.
- Merge the changes from the contributor’s branch into that release branch.
- Run tests and quality checks.
- If the contributor’s contribution is approved, pushes those merged changes into the central repository.