Agile SCM: Build Management for an Agile Team

"big bang integration" at the end of a release/iteration, and to provide a regular rhythm for the development team to tackle integration issues early and aggressively, one small piece at a time.

Release Build

The Release Build is the "formal" releasing process for the application. Typical steps of a Release Build could include:

• Apply a label to the codeline,
• Get a copy of the codeline (workspace or instance) on a "golden" build machine,
• Build the application,
• Possibly test the application and report on those tests,
• Package the targets of the build by either checking them into the version control tool and label as appropriate, zip up the release for distribution, or possibly even run installer software against the release to package it for distribution,
• Email a report showing the results of the build.

While the integration and release builds are similar in many ways, the primary difference is that the release build is intended to package and store the build results for installation and distribution purposes. The integration build is intended to test the quality of the codeline and offer feedback to the development team while the recipient of the Release Build is typically the developers’ customer.

To be even more specific about the differences between an Integration Build and a Release Build, the following points are worth noting:

• You typically don't apply a label with an Integration Build, you do with a Release Build
• Integration Builds typically operate on the latest (tips) on the branch, not always the case with a Release Build
• Integration Builds run exhaustive tests on the build, not always the case on a Release Build
• Release Build packages the release for installation and distribution, mostly not the case with Integration Builds
• Release Builds include automated CM reports like BOM (bill-of-materials) and CR (change-request) reports - rarely the case with Integration Builds

The last point worth noting with Release Builds is the fact that they occur only when the development team intends to package a release of software for distribution (Test or production environments). Therefore, Release Builds occur far less often than the typical Integration Build.

Scale and Agility

We have identified the following types of builds and noted that each takes place at different levels of scale. One of the varying levels of scale is that of visibility (or organizational scope/impact). Another varying level of scale is that of frequency and duration (or project planning scope). At each level of scale, a slightly different set of needs and concerns must be resolved using a slightly different set of trade-offs:

It’s useful to note that while the various kinds of builds work with the same inputs (code, tools, build scripts, etc) and should be similar in many ways, they differ in subtle, but important details. Allowing for these small differences helps you to be more agile and focus your energies on the important task of the moment. Each build should be as close to the final product, but no closer than necessary. For example, the Private System build may