CM: THE NEXT GENERATION - Agile Configuration Management

Revisions Across Streams

Many large CM shops that have not switched to a stream-based main branch model (from a single main branch model) will debate the merits of each. Although the "single main" model looks simpler - just one main branch where everything goes - it is not. Everything does not belong in the same main branch. The natural process is to start working on a release when resources permit and to continue to support it until its retirement. The single main branch model forces you to create branches for work done before the main branch switches to the next release, and then to maintain a new set of branches after the switch to the subsequent release. Each release has three different processes to follow. Again the pressure to simplify causes short-circuiting of the process, such as not checking in next release changes until the next release is available in the "main".

The main branch per stream model is simpler and more natural. Each stream has its own branch. The stream process always works the same, both across the life of a stream, and from stream to stream. This eliminates any artificial pushes to close off one stream or open up a new one. Instead, a bit of common sense prevails - don't do widespread changes on your next stream before your current one has started to settle down. This will help minimize parallel changes.

To further minimize parallel changes, most modern CM tools allow you to share revisions from one branch to another. If release 2 uses release 1 versions of some files, than fixes to those files in release 1 can be automatically propagated to release 2. Where this is not the case, the CM tool should allow you to track which fixes have to be applied to which streams.

In an ideal CM tool, you don't have to specify branch/stream history for the tool to use when automatically sharing revisions across branches. This is inferred automatically by the CM tool. The CM tool should be able to use its product history to identify when and from where each branch should be made. It should also allow you to select a product, stream and promotion level and then automatically give you the correct view, without having to write a view specification. When you have a process/toolset with this level of support, your agile CM process becomes more agile, not only within each development stream, but also across development streams, allowing developers to easily switch from one view to another at will.

Build Automation

We've already discussed how automation could help to define baselines and views. But one of the real potential areas for automation is with builds. It's not sufficient in an agile environment to have to always rely on system (i.e. build manager generated) builds. Even if the build manager rebuilds every hour or two, your development productivity will likely be significantly reduced. I remember when Borland Pascal first hit the market and took a complex or long compile/build cycle and turned it into a few keystrokes and typically a few seconds to a few minutes. Great productivity strides were made. These would not have been made if the build capabilities were not in the hands of the developers.

Developers need to turn their work around rapidly. If not, there will be resistance to adapting requirements mid-stream. It will take significantly longer to run unit tests as each system build iteration reveals only a small portion of the developer bugs. In the hands of the developer, 30 or 40 iterations in a day is not uncommon. This