Software Configuration Management Patterns

[article]

When I started out as a software developer I worked with a team of people who taught me that how we do things and why we do things as developers is as important as what we do. In other words: process isn't only the concern of senior developers. Everyone should care about finding ways to work better. Of course, the more influence you have over the team, the more you should care, since you'll have a bigger impact on the bottom line, but there are things that everyone can do to make their own work better and perhaps lead by influence.

Perhaps only a few should thing globally. Everyone should act locally. For example, any developer should be able to add tests for their code, independent of the team's global policy.

Goals and Intentions of the SCM Pattern Language

Perhaps the common definition of SCM patterns is that given in the book Software Configuration Management Patterns. A pattern language guides you along the process of building a thing, the SCM pattern language is not a guide to building every SCM process.

I could argue that most teams should be more agile than they are now, and could be so without sacrificing anything. Many restrictive (or non-agile) processes seem to have their origins in lack of trust, or an unreasonable fear of risk, rather than reasonable business goals. You are the one who best understands what your team is doing now and how it needs to improve.

The Role of Tools

The first question I get about SCM is often "What tool should I use?" Like all things, tools influence the way that you work. If you have a tool that makes something easy you may do something one way. Without that tool another approach may be almost as good. My advice, which is not often well received, is 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 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.

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 Techwell.com,  and a former section editor for The C++ Report. You can read Brad's blog at blog.bradapp.net.

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 steve@berczuk.com or visit berczuk.com and follow his blog at blog.berczuk.com.

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 steve@scmlabs.com.

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

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

Upcoming Events

Sep 24
Oct 12
Oct 15
Nov 09