  | 1 of 26
 |   |
| | 1 of 26
| |
Over time, a software system can exist in many versions:
Software Configuration Management (SCM) is concerned with all of these.
SCM Activities
Version control
Build management
Environment management
Change management
The last two are new.
The first two we have discussed in isolation.
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.
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
Major issues are
Coping with the different environments in which the software may need to be installed and/or built.
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)
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.
Luckily, there’s automated support for this aspect of SCM, which we will cover separately.
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.
Build manager is told what external libraries are needed
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.
In current practice,
In current practice,
Large projects composed of multiple subprojects are discouraged
In current practice,
Large projects composed of multiple subprojects are discouraged
in favor of smaller, independent projects (e.g., one per original subproject)
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)
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.
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.
We’ve spent time looking at version control already.
We have lots of flexibility in terms of
SCM challenges us to think strategically about how to exploit that flexibility.
Main trunk moves forward in time
Each planned release is a branch from the trunk
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.
Even in smaller projects, the issue of change propagation across code lines needs to be kept in mind.
Open source projects often have a structure of
Typically, the main release branches can only be modified by the core developers.
Remember that, in the git distributed model,
distinct from, but
“synced” with
the central branches.
git anyway.
| | 1 of 26
| |