This month we will talk about how using some basic patterns can help build a software configuration management process that works well with your agile development environment. We will discuss how codeline policy, private workspaces, smoke tests, private system builds, integration building, unit testing, and regression testing all work together to enable you to maintain an active development line.
When working in a release engineering or SCM role, you begin talking and thinking in terms of software configuration management as an end in itself. If you are developing software, SCM is often ignored and treated as something necessary that hangs in the background or, if visible, it's seen as the version control tool. Neither view of the world will give you the most effective environment. It is important for everyone to remember that SCM is a part of the environment where code is developed. It’s easy to forget this when, as a practical matter, day-to-day work involves immediate import, no matter how much you want to think in global terms. Since we tend to specialize, much of the literature on SCM is focused on the practice of SCM without necessarily fitting that practice into context.
When Brad and Steve began working on the pattern language for agile software configuration management, which evolved into the book Software Configuration Management Patterns: Effective Teamwork, Practical Integration, we had this in mind: patterns and pattern languages, by their nature, help place things in context. In this article we will provide an overview of part of our SCM pattern language with the goal of showing you how to present SCM practices in the context of the entire development process.
Patterns and Pattern Languages
A great deal has been written about patterns and pattern languages, and it is a topic that can take a while to master. In the book A Timeless Way of Building, Christopher Alexander describes a pattern as something that “describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.” A shorter definition is “a rule that describes what you have to do to generate the entity which it defines.” Alexander also describes the importance of context in A Pattern Language “… every pattern we define must be formulated in the form of a rule which establishes a relationship between a context, a system of forces which arise in that context, and a configuration which allows these forces to resolve themselves in that context.”
There are a number of collections of best practices, but we often keep hidden the context of how these practices fit in with our larger goals. Brad and Steve wrote a pattern language for agile software development that is organized around SCM practices. This pattern language (which you can learn more about at http://www.scmpatterns.com/) defines some core development practices related to SCM. The benefit of this approach is the likelihood of increased success when applying the patterns. Also, those who are performing SCM-related tasks on a daily basis will have a better understanding of when to perform the tasks.
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.
Finally, 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 is going beyond an active development line and changing the codeline policy appropriately.
Putting it All Together
If you read this far you may be thinking, “Codeline policy and build issues are SCM, but isn’t testing QA?” In a sense that is correct, but the fact that they are separated into two different groups is an organizational, and perhaps historical, artifact. In extreme programming teams, developers write tests and use version control in addition to coding. There is a role for testing experts, ideally fully integrated into the team as either someone who helps customers write acceptance tests or on the development team, helping developers with their testing technique. Likewise, there is a role for software configuration management in an agile project and, indeed, all projects would benefit by a more integrated view of SCM.
In addition to the abstract benefits of understanding the global value of SCM solutions, implementing SCM processes with this in mind will make it easier for the entire team to embrace the SCM and appreciate the value that it adds.
Conclusion
Often we focus on our particular discipline and lose track of the goal of a software project: to build software that serves a customer’s needs. Testing, SCM, and coding should be part of every developer’s toolkit. Some will know more than others about a given discipline, but the disciplines need to work together well.
Acknowledgements: Ron Jeffries provided input into this article. To learn more about xtreme Programming visit www.xprogramming.com.
