CM is complex enough without having to worry about managing releases! Release management, however, isn't just part of CM, it should be driving your CM solution.
Release management deals with defining, using and managing the set of deliverables (the Build), for all of your customers. This includes the creation of records to subsequently identify release contents, the creation of variant builds, patch releases, incremental releases, and the support of parallel streams of releases (older product releases, current release(s) and future releases). It also deals with the ability to know what’s in a release and to compare one release (e.g. one being sent to a customer) to another (e.g. the one the customer currently has so that the customer is well aware of the changes being made to his environment and how they match up against his requirements). In an end-to-end product management environment, release management spans the entire spectrum from requirements management through to product retirement.
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 labeling 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. If release dates and criteria could be cast in stone and customer variant requirements minimized, this might be a successful model. 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.