New Developments in Builds and Deployment Management


In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.

The very first generation of CM tools dealt with support for build operations. Typically, this was through the inclusion of a facility such as a Make utility, and perhaps some tools to help build Make files. But as we move into the next generation of CM tools, it is also more important to be able to manage the builds at an information level. Build Management moves from the earlier build operation support and tagging functions, to wider traceability and better information accessibility. And beyond the build operations themselves, there are additional benefits as we move into the next generation of Deployment 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 identifying 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. A baseline, though, is meant to be a change reference.  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 many changes to it. I also like to define a build by starting with a previous build and adding changes to it. Either of these options work well for me. In the first case, baseline references can be defined according to what best suits the CM process.  The build clearly defines what has changed since the baseline and 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 that show how builds evolve. This gives a history of a build. By combining this with a decent query/navigation facility in a next generation CM tool, 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" (this is an 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, 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.


About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.