Taking the Complexity out of Release Management

An even better design would have your variants specified at run-time, minimizing the number of test builds you'll require. It's actually not hard to design to these criteria and it will cut down the number of builds you're doing, along with the associated testing and test resource logistics.

Your source tree browser (in your CM tool) should be able to browse the Superset of all components. If its a good browser, you'll be able to modify the view just by specifying the variant tags to the browser. So instead of having R4EnglishProf R4EnglishEnterprise R4GermanProf etc. branches and baselines, you'll have a single R4 stream with evolving baselines, and tag sets to identify the variant builds that you need. If your variants are all run-time configurable, you may not even need any tags - just a single build per release. This is where working with the Design team really pays off - to minimize complexities, not just for the build team but for the developers who need to do their own builds as well.

Another side note - having a single build for multiple variants won't necessarily reduce the amount of testing, but it will eliminate the logistics for your test bed (i.e. which build components are loaded, etc.) - you just reconfigure what you've got, hopefully using a variant configuration file which doesn't have to change from release to release.

Make Baselines Meaningful - Define Build Increments in Terms of Changes to the Baseline

The release is delivered from development. You've defined and frozen a baseline. Patches will occur. There may be variant builds. Perhaps customized upgrades are required. There may be a seemingly endless train of builds for a release stream. But rather than defining new baselines every other day, define Build Increments on top of your baseline. A series of 40 baselines makes it difficult to relate to any of them. If you instead have 5 or 10 baselines in a release stream, with several build increments in between, each baseline becomes a reference point for your whole team.

Build Increments are defined in terms of a baseline plus a set of changes. If you have change-based CM system you'll readily be able to identify the differences between each increment as a set of a few to a few dozen changes. If not, you're likely to see dozens to hundreds of changed files instead - do yourself a favor and move to a change-based solution. Comparing two Build Increments built on the same baseline is generally an easy task, and a meaningful one, resulting in a list of changes (and hopefully their descriptions).

It’s difficult, at best, to manage releases in terms of changed files. A change-based system will allow your Change Review Board to review and approve requests for a particular product stream and they will be able to clearly identify which of those changes are in each successive build. The promotion model will work on changes, build comparisons will be done in terms of changes, etc.

Establish Clear Consistent Release, Baseline and Build Identification

Assign regular identifiers (Build Ids) to the Build Increments and use them to track your testing and problem reports. Put the Build Ids in the customer executable (along with the tags used to define the variant subset) so that it is easy to go from a customer site back to the specific build information. This also makes it easy to track your customer sites in the delivery portion of your CM solution.

For release identifiers, I prefer short names - you're going to want to combine them with other attributes and they'll