CM: THE NEXT GENERATION of Build Management

Build Management covers a lot of ground because in software development, builds are fairly significant events that touch nearly the entire product team. Let's look first at the operations of defining and identfying builds before moving on to the topics of comparing builds and of build automation.

Defining a Build
There are different ways to define what is in a build.Some do this by tagging every file revisions with the build id.This can be tedious, or if automated, resource intensive.Some define a build by defining a baseline. However, a baseline is meant to be a change reference, and creating a new baseline definition every time a build has to be tracked sort of defeats the purpose of having a baseline reference.It can also be resource intensive.

I like to define a build by starting with a pre-existing baseline reference, and adding a bunch of changes to it.I also like to define a build by starting with a previous build and adding a bunch of changes to it.Either of these work well for me.In the first case, baseline references can be defined according to what best suits the CM process, and the build clearly defines what's changed since the baseline, and it does so in terms of change packages (as opposed to file revisions).In this case:Build = Baseline + Set-of-Changes.The second case comes from more of a realization that builds are done serially, adding changes each day or so to do the next build.In this latter case: Build = Previous-Build + Set-of-Changes.

This latter definition is actually preferable, as the Build/Previous Build relationships form a tree which show you how builds evolve. This gives a history of a build.Combine this with a decent query/navigation facility in a next generation CM tool, and you can quickly navigate through the changes that have gone into recent builds.

First Order Build Object, With an Identity
A build needs to be a first order object in a CM tool.A tag just doesn't cut it.The build will go through promotion levels.Significant milestones for the build will be tracked and it should be possible to add additional attributes against the build besides the baseline it's built upon, the previous build and the set of changes.For example, a description of why the build was created, the build results, perhaps a distinguishing title, the product it applies to, and the release stream would all normally be tracked against a build record.Call it a "build" a "build record" or and "ECN" (Engineering Change Notice), to best suit your process environment.I like to refer to it as a "build notice" or ECN prior to creating the build, while a notice or what's going into the build is being created, and then as a "build" in the past tense, that is, once the build has been created.Below is an example gantt-like chart showing the progression of successive builds as they reach the various milestones, or states, along their useful lifetime.

The build should have a state flow associated with it. It should go from a planned state, to a notice definition state, to a built state, and then on to various test and production states such as: sanity tested (stested), integration tested (itested), verification tested (vtested), alpha test, beta test, production. Obviously not all builds are going to go through all of these states. Most will wind up at a "stested" or "itested" state.

This first order build object must have a clear and unambiguous name associated with it, whether automatically generated by the CM tool or manually selected by the build/CM team.The name must be itself integrated into the actual build