Taking the Complexity out of Release Management

In this article we will focus on aspects of a Release Management strategy which reduce complexity, minimize branching and ensure accurate identification and descriptions of your releases. We’ll explore the need to:

• Establish a Product Road Map and use it to minimize branching
• Manage the Superset in your product component tree, but Build and Deliver Subsets
• Make Baselines meaningful milestones and use Build Increments between Baselines
• Establish Clear Consistent Release, Baseline and Build Identification
• Select CM tools that make it easy to compare, report on and browse differences between Builds and Baselines

Establish a Product Road Map

It's too easy to use ad hoc Branch Labelling or Directory Copying to define and freeze releases. As support issues arise and as you realize that your verification failed to uncover some significant bugs, the multiplication of branches and re-releases sets in. What you really want is an overall game plan. Your product needs a release strategy that is driven by market and support requirements, not by your tool, team or process capabilities - the latter should fall out of your requirements. Your design architecture will play a significant role in how quickly you can react to these requirements, but you need a Product Road Map up front, one that is simple, but flexible.

Many (most?) shops define a "main" branch and develop out of the branch, merging back in, and perhaps branching again to define a release or to support a release. It seems like a simple strategy because there's a single main branch. And if release dates and criteria could be cast in stone and customer variant requirements minimized, this might be a successful model. But in the real world, the release process is a long parallel-stream process. The single main branch model is very complex precisely because it does not map on to the real world requirements where development teams need to be working on a new releases even before the previous release has made it out of QA.

So let's start with a different framework. Look at the Product Road Map - jump 5 years ahead if you need to. Release 3 is in the field. Release 4 is in verification, almost ready for beta, and work on release 5 has started. Three parallel release streams, all needing support - perhaps more in the future. The support team may be trying to move users on to the latest release, but it knows that it will have to maintain parallel streams. And it doesn't want the support process for one release stream to change just because a new release stream has started.

Rather than using a main-branch centric process, try the following. Look at the Product Road Map. What does it say about how you need to roll out and support releases of your product. The roads can actually run in parallel. They don't have to run end to end (i.e. main branch) with a sudden left turn everytime you need to define a support point.
Minimize Branching

Start with your current release branch, say the R3 stream. When it's time to start working on R4, start working on it, but don't “branch the world” - create an R4 branch (if none yet exists) for each component/file when the first non-R3 changes for the component/file go in. Continue to make changes to R3 in the R3 stream. The R3 stream should live forever on its own. It doesn't have to merge back into some artificial "main" trunk. The process for supporting it doesn't need to change when R4 comes out - it just slows down as things stabilize.

Changes to