Keeping Agile Projects Safe

There are many aspects of SCM that are relevant to the agile project the difficult part is knowing when to apply them. We want agility, not chaos. Some practices work together to build an effective development environment with the right amount of SCM practice.

Your agile project should use a simple branching structure. Branches of development for a configuration item's source-code library files are commonly called codelines . One or two codelines are usually sufficient for agile projects that don't require multiple parallel releases or variants.

The key concepts for organizing the evolution of your code are: a Mainline , an Active Development Line , and a Release Line . A Mainline is the single, central codeline that controlled library artifacts are checked in to. Having a single integration point makes it easy to re-create the latest state of the SCM-controlled items. An Active Development Line is a codeline that is set up with a Codeline Policy that permits ongoing work to be checked in without overly rigorous precheck-in validation. A Release Line is a codeline for system states that are available to customers for fixing system problems in preparation for your regular release cycle. A Release Line has a more restrictive Codeline Policy that ensures stability.

Having a Release Line simplifies the SCM rules and allows you to be a little less strict on the check-in policies for the Active Development Line . With these two separate codelines in place, the developers can make their hourly or daily changes into the Active Development Line , and the customer-release process can use the more carefully controlled Release Line .

Here is what a typical agile developer's day looks like in terms of the SCM strategies or patterns they use:

Each developer works in a Private Workspace that contains the code that the developer is working on, populated from a Repository a single point of access for everything that a developer needs to build his or her project. The developer gets external components from a Third Party Codeline . If he or she does not want to build the entire system from scratch, the developer can populate some of their workspace from an Integration Build , which is a snapshot of the codeline.

The developer, progressing through the day, will check changes into the Active Development Line so that they are visible to the rest of the team, as well as available for the integration build. Because the codeline isn't required to be bullet-proof, the developer does not need to run exhaustive tests before checking changes in. But he or she should create a Private System Build , which is just like the Integration Build , and run a Smoke Test on the result to make sure that the check-in will not cause any problems. Since this cycle repeats with every developer, the current state of the system is available in the Integration Build .

The codeline may have mistakes in it, but they should be few and minor. The team relies on the Smoke Test to catch show-stopper defects and on Unit Tests to ensure that changes don't change any interface behavior for the module that the developer is testing. After the I ntegration Build, the Regression Tests , as well as the full suite of Unit Tests , are run to catch integration issues. It is a trade-off, but it's a reasonable one, since the only way to ensure a pure codeline would be to have a developer lock the entire codeline, run a full suite of tests, check in the changes, and then unlock the codeline. This approach would severely limit progress, and for agile projects you realize more value from changes in functionality early on. Once the project reaches a certain milestone, the code can be branched onto a Release Line , where a more restrictive Codeline Policy may be in effect.