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.
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.