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.