To learn more about patterns and pattern languages, some good starting points are:
- Some books by Christopher Alexander, et al., such as A Timeless Way of Building, The Oregon Experiment, and A Pattern Language
- The Hillside Group’s web site, at 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 more concerned with someone breaking the build due to careless change rather than how often the code changes. While delayed integration does cause problems, concerns about breaking the build are valid. For active development line to work, other patterns should be in place to ensure that the rapid changes will not harm the codeline quality too much.
To address the issues of build integrity, code should be built before checking it, in addition to testing it. To build the code, you need to have a place to put the code.A private workspace allows not only this, but also the ability to do development, testing, etc. To verify that the code builds, developers can do a private system build pre-check-in. Once developers check the code in, it is built in an integration environment using anintegration build.
A private system build is as close as possible to the integration buildand official system build. Setting up a private system build can assist in avoiding issues caused by developers having a different approach to building than that of the integration build.
After each developer checks the code in, it is still important to integrate it 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. It covers essential functionality and runs quickly. “Essential” and “quickly” are both concepts that are defined by each individual project, but if the goal is an agile codeline, you don’t want a one hour smoke test.
This leaves the issue of how to test the code. A unit test is a low level, detailed test of interfaces that developers run on the code that they are working with. Unit tests can be written using a unit testing framework such as JUnit for Java code, cppUnit for C++ code, etc., though it’s not essential to have unit tests. A regression test is an exhaustive system-level test used to verify that known problems 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 either after the integration build or before checking code in to a codeline that needs to be stable.