This month we will talk about how using some basic patterns can help you build a software configuration management process that works well with your agile development environment. We will discuss how Codeline Policy, Private Workspace, Smoke Test, Private System Build, Integration Build, Unit Test, and Regression Test all work together to enable you to maintain an Active Development Line.
When you work in a release engineering or SCM role you can start talking and thinking in terms of “Software Configuration Management” as an end in itself. If you are developing software, you often ignore SCM, treating it as something necessary that hangs out in the background, or, if it is visible, you think of SCM as being “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 you develop code. It’s easy to forget this when, as a practical matter, your day-to-day work has you working with things of 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 practices of SCM without necessarily fitting the practices into context.
When Brad and Steve were 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 you to place things in context. In this article we will give you 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
There has been much written about patterns and pattern languages, and it is a topic that can take a while to master. For the purposes of this discussion there are a few things to know. 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 which describes what you have to do to generate the entity which it defines.”
Alexander 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, etc, 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 that you are more likely to have increased success when applying the patterns and those who are performing SCM related tasks on a daily basis will have a better understanding of when to do the tasks.
To learn more about patterns and pattern languages, some good starting points are:
Some of the books by Christopher Alexander et al: A Timeless Way of Building