Agile SCM: It’s All Related

• , The Oregon Experiment , and A Pattern Language

• The Hillside Group’s web site: www.hillside.net

SCM in Context

The pattern language for agile SCM starts with the basic idea of an Active Development Line . In essence, an Active Development Line is a codeline that has a Codeline Policy that permits frequent check-ins. If you have worked with a team developing software you might be concerned more about someone breaking the build because of a careless change than with how often code changes. While delayed integration does cause problems, your concerns about breaking the build will be valid. For Active Development Line to work you need to have other patterns in place to give you some confidence that the rapid changes will not harm to codeline quality too much.

To address the issues of build integrity, you want to be able to build the code before checking it in as well as test it. To build the code you need to have a place to put the code, a Private Workspace gives you a place to put the code, do your development, testing etc. To verify that the code builds, developers can do a Private System Build pre-check-in. And once the developers check the code in, it is built in integration environment using an Integration Build .

A Private System Build is a build that is as close as possible to the Integration Build (and official system build). Setting up a Private System Build can help you avoid issues caused by developers having a different approach to building that the Integration Build .

After each developer checks the code in, you will still need to integrate the code in a central place. To build the code in an integration workspace, set up an Integration Build which is the “official” build.

The first step in addressing testing issues is to define a Smoke Test that developers run pre-check-in. A Smoke Test is a basic test of the important aspects of the system. The Smoke Test that you run before checking in code covers essential functionality, and runs quickly. “Essential” and “quickly” are both concepts that you have to decide how to define for your project, but if your goal is an agile codeline, you don’t want a 1 hour smoke test. This leaves the issue of How do I really test the code? Unit Test and Regression Test address this.

A Unit Test is a low level, detailed test of interfaces that developers run on the code that they are working with. You can write your unit tests using a unit testing framework such as JUnit for Java code, cppUnit for C++ code, etc, but that is not essential to have unit tests.

A Regression Test is an exhaustive system level test that verifies that known problem have not re-appeared in the code. Construct unit tests based on known issues, or by an analysis of likely failure points. Always run the Regression Test after the Integration Build , or before checking code in to a codeline that you need to be stable.

Lastly, the Codeline Policy is a description of what procedures to follow before checking code in. A Release Line may have a more restrictive policy than an Active Development Line , for example.

The figure below shows how the patterns fit together. An arrow from pattern A to pattern B means, in effect, that pattern B is necessary to ‘complete’ pattern A. This is a structural relationship and does not have any defined implications about the sequence in which the patterns are implemented. The key thing is that you