Software Configuration Management Patterns


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:  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 (i.e., clean, install, update, test, docs, etc.)
  • Physical software design patterns (a.k.a. code architecture):  Best practices for how to store and organize assets under configuration management across one or more repositories, and across directory-tree structures within a repository in order to assist not just software design/architecture, or to minimize build-dependencies or build-times, or assist traceability and/or configuration auditing
  • Change Control: Setting up, chartering, and running and facilitating a CCB (see patterns from Ellen Gottesdiener's book Requirements by Collaboration [7]), deciding policies for obtaining stake-holder buy-in
  • Configuration audit/review:  Conducting or automating audits and reviews of builds and baselines
  • Configuration status accounting/reporting: Tracking and managing the status of requests, changes, and baselines the face of multiple releases and/or variants, change propagation and coordination with multiple codelines and/or sites and/or vendors/suppliers, devising and implementing promotion lifecycle models
  • Distributed and/or multi-site SCM: Including integration coordination/ synchronization topologies for distributed parallel development
  • Multi-component and/or product-family SCM:  Effective strategies for working with multiple versions of multiple components being integrated into a system, and/or for families of components with subsets of components and component versions being combined and configured to build/package/ release multiple products in a product-line
  • SCM Solution selection/deployment/architecture: Plotting the particulars of how SCM will operate within your organization, defining an overall process framework and governance, evaluating SCM tools and technology, administering and deploying/upgrading tools and processes across a network of servers and repositories and workspaces, coordinating and synchronizing upgrades of repositories and workspaces
  • Database CM:  CM of databases, stored procedures, database schemas and views, queries and reports; configuration and use of database workspaces and production sandboxes and database code integration.
  • Web SCM:  Configuration and content management of websites and web software, including all artifacts (code, HTML/XML files, XML schemas and ontologies, JavaBeans and EJBs, managing JAR/WAR/EAR files)
  • Service-Oriented SCM:  SCM for service-oriented architecture, and service-oriented architecture of SCM itself (i.e., CM services model of dart [8])
  • Enterprise CM:  Managing change across the enterprise, CM of enterprise architecture, CM with and for business processes, workflow, B2B and EAI

The Pattern Language Angle

As previously mentioned, patterns describe individual solutions to a recurring problem in a context. A pattern language is more like a seasoned "trail guide" thru a set (or family) of related patterns that build upon one another. They help "connect the dots" to realize a more complete overall SCM domain solution. Documenting more proven SCM patterns is important, but so is being able to successfully select from and navigate through a growing body of SCM patterns. In addition to inviting you to document and disseminate more SCM patterns, we also heartily encourage you to help others see how patterns work together. Possible topics include:  

  • Connecting and inter-relating patterns: Taking some existing named best-practices and showing how they work together to create a larger solution (where to start, where to go next, what factors to consider in choosing the next stop on the destination). One possible example would be to take the patterns in the software configuration management patterns, and in AntiPatterns and patterns in software configuration management  [9] and relating them all together to "connect the dots" between them.
  • Sharing experiences with power of pattern names to convey an SCM concept in a tool-independent way, and/or with a suite of patterns to create a shared language in one's own shop for discussing and disseminating SCM problems/ solutions and process
  • Relating patterns or pattern-languages across domains: For example, taking a set of SCM patterns and relating them to a set of software testing patterns, or a set of project management patterns, or a set of requirements management/ analysis patterns, or software architecture patterns.
  • Rationale for using patterns and pattern format (and pattern languages) as an effective means of naming and sharing knowledge of SCM best practices (as opposed to the approach currently taken by BOKs such as PMBOK and SWEBOK)

About the author

Brad Appleton's picture Brad Appleton

Brad Appleton is a software CM/ALM solution architect and lean/agile development champion at a large telecommunications company. Currently he helps projects and teams adopt and apply lean/agile development and CM/ALM practices and tools. He is coauthor of the book Software Configuration Management Patterns, a columnist for the CMCrossroads and AgileConnection communities at,  and a former section editor for The C++ Report. You can read Brad's blog at

About the author

Steve Berczuk's picture Steve Berczuk

Steve Berczuk is a Principal Engineer and Scrum Master at Fitbit. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, he is a recognized expert in software configuration management and agile software development. Steve is passionate about helping teams work effectively to produce quality software. He has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT, and is a certified, practicing ScrumMaster. Contact Steve at or visit and follow his blog at

About the author

Steve Konieczka's picture Steve Konieczka

Steve Konieczka is President and Chief Operating Officer of SCM Labs, a leading Software Configuration Management solutions provider. An IT consultant for fourteen years, Steve understands the challenges IT organizations face in change management. He has helped shape companies’ methodologies for creating and implementing effective SCM solutions for local and national clients. Steve is a member of Young Entrepreneurs Organization and serves on the board of the Association for Configuration and Data Management (ACDM). He holds a Bachelor of Science in Computer Information Systems from Colorado State University. You can reach Steve at

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!