Software Configuration Management Patterns

to understand what your work process is, what you want it to be, what your constraints are, and then pick a tool that supports them. Then you can think about whether you should use different tools.

The pattern language in Software Configuration Management Patterns does not care about tools beyond having some sort of version control system and some sort of build process tool. Of course, some tools make implementing some patterns more transparent than other tools do.

Applying the SCM Pattern Language for Process Improvement
A frequent complaint is that teams spend too much time stabilizing their codeline before releases, resulting in developers idling while the team integrates (and thus delays that cascade into subsequent releases). One approach to resolving this situation is creating a release branch and dividing the team's effort into stabilization and new release activity. This does not always work as expected if the release branch takes a long time to reach "release quality." Time spent waiting for the release to be ready is replaced by time spent on merging release line fixes into the main line. The SCM Pattern Language provides a map to making resolving some of these issues. ⁶

A patterns approach would analyze how the problems relate and provide solutions that build upon each other. If your team has frequent releases you would attempt to focus most of your work on a single Active Development Line , which would have a Codeline Policy that allows for frequent check-ins, but only after they run a suite of Smoke Tests and Unit Tests in their Private Workspaces . Developers will also be expected to do Private System Builds to provide added assurance that their check-in will not break the build. Later on an Integration Build will build everything, and perform extensive Regression Tests . By the time you are ready to start a Release Line , the code should be fairly stable, and you should not need to perform complicated merges between codelines.

While having a Release Line (applying a single pattern) relieved some pain, applying the Release Line pattern in context gave you a greater benefit.

The Missing Patterns
The SCM Pattern Language as it appears in the book Software Configuration Management Patterns , and the other patterns that are in the Streamed Lines Pattern Language and other places do not solve every problem the development team faces. Often, the most important patterns to document and disseminate are the ones that the "expert practitioners" use regularly and talk about, but never take the time to formally write-up in a book or paper that will be readily accessible to users who need it most. Here are some areas for which additional patterns would be useful. Some of these come from the list of patterns that Brad and Steve didn't include in the book for a variety of reasons. Many come from questions that we've been asked, either on the SCM Patterns discussion list, or in private.

We invite you to think about practices that seem to work well in your environment, practices that seem to solve problems in a good way and that balance many difficult tradeoffs. Maybe you know the basis for another pattern that hasn't been documented yet.

• Build Management - e.g., for using or structuring make/ANT files and their corresponding "rules" (maintaining build dependencies, building all or part of a system, supporting multi-platform or component-based building, parallelizing builds or using a "build-ring", standard sets of Make/ANT targets (e.g., clean, install, update, test, docs, etc.)
• "Physical" software design patterns (a.k.a. code architecture) - for example, best practices for how to store and