CM: THE NEXT GENERATION - Agile Configuration Management

Change-based CM

To start, let's visit the obvious. An agile process which is built on file-based CM, as opposed to change-based CM, may make the up-front tasks easier for some developers, but overall, it will do a lot of damage to any attempt to make the entire process agile. Promoting files, rather than changes, is both unnatural and error prone. It complicates the process forcing short cuts. Often it's left up to the developer to ensure that everything will flow properly.

Changes really need to move through the process as units. This is not to say that tasks, features or issues need to - just the changes themselves. If I go to implement the first part of a feature by changing 4 files, I really don't want someone to try to move any less than those 4 files through the process. Nor do I want to have to specify dependencies on other changes in terms of files. I don't even want to have to know what files are involved in the dependent changes. And as a CM manager, I'm much happier promoting a dozen changes than 47 files.

And change-based CM simplifies peer reviews. A simple change identifier is all that's needed to identify code for a review. Most change-based CM tools will allow you to generate a code delta report from this identifier. Some will even let you track peer review comments against the change so that the comments are not lost in the shuffle.

Promotion Support Without the Blockage

You've got a choice: you either have a branch-based promotion model or you hold up check-in operations until the build has been successfully verified to the appropriate set of criteria. At least that's what many will tell you, but don't believe it. Both choices contribute to a non-agile process.

In a branch-based promotion model, there's merging that has to be done all the way up the model, and the question about whether this is a developer or CM manager task. This in turn tends to result in a compromised model in an effort to minimize merging.

If you hold up check-in operations, not only do you have a lot more parallel check-outs, and resulting merging (and hopefully re-testing), but when merging and testing is done on the main branch, the changes are not always still current in the minds of the developers. And this compromises the quality of builds, which delays the rapid interation goals of your agile process.

So what's the solution? It's two-fold. First realize that, especially in an agile environment, almost all changes are going to be checked-in in an order that is perfectly acceptable for promotion. The process should be optimized to this behavior. The branch promotion model optimizes so that the worst case can be dealt with easily. However the worst case rarely happens and you end up repeating merge operations almost mindlessly, so heaven help you if merges between different promotion levels differ.

Secondly, you need process/technology that allows you to promote a change by changing its (promotion) status and nothing more. You also want it to make you aware of any dependency violoations when you promote, whether these have been explicitly stated or implicitly inferred. Your tool technology should allow you to view baselines based on change promotion states. It should allow automated baseline definitions in the same manner. Now this is not a trivial task for a tool. However, it is possible to automate these tasks so that your views and your baseline definitions are provided with little or no human intervention (other than a view selection).

Stream-based Architecture and Sharing