Taking the Complexity out of Release Management

[article]
Summary:

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.

Pages

About the author

Joe Farah's picture Joe Farah

Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at farah@neuma.com

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 22
Sep 24
Oct 12
Nov 09