Dan Wellman: What is SCM?

Steve Berczuk: There's a definition of SCM from an IEEE standard that says that it involves things like configuration identification, control, review, build management, process management, and teamwork. But that doesn't explain why people might care about SCM. I like to think about SCM as the things people do to make it easy to collaborate on a software project. It includes things like source code management and build management, but also aspects of the software development process like testing that validate that the code does what it is expected to.

Testing is actually an important aspect of SCM. With audit and control mechanisms in place, you can identify that things have gone wrong but not the impact of the problem or when they went wrong—and the latter two are what most people care about.

Dan Wellman: How strongly are SCM and a testing strategy intertwined?

Steve Berczuk: There's a balance between checking in code frequently and keeping the code line stable. Frequent check-ins mean more frequent integration, but every time you change something, you risk breaking something. Then again, waiting too long to integrate also has risks. If you are disciplined about testing, you reduce the risks that any change will break the code line. So fewer, more frequently integrated code lines are possible. A single code line (using the Main Line pattern) can be very simple to manage, but would be very risky without a good approach to testing. So the testing strategy you choose has an impact on the SCM model you can use effectively and vice versa.

Dan Wellman: What preconditions are required to make working on a single main line a smooth process? I've seen many "merge conflict hells" before.

Steve Berczuk: One way to avoid merge conflicts is by everyone on the team working in small steps with frequent commits and good testing discipline. Another is having modular code that makes it less likely that people working on different features will be touching the same code. Doing both together works especially well. In the end, communication among team members is the best way to avoid issues. If you know what others are working on and you think that you might step on someone else's work, say something. The code is a form of communication, but not the only one you have.

Dan Wellman: How does an SCM process relate to a team's development process?

Steve Berczuk: In the SCM Patterns book, I discuss how SCM, architecture, and process relate. Your process and architecture can make it easier for some sorts of development processes to work than others. And some SCM processes can make it hard for other processes to work.

For example, if you have decided that the way to keep your code line stable is to have an SCM process that favors infrequent integration, then you're not going to be too successful at adopting an agile process. Conversely, if your SCM policies encourage frequent commits supported by testing, then you can move to an agile approach more easily.

A monolithic architecture makes testing more difficult, making it harder to be agile. It's difficult to have frequent commits to fewer code lines if every change can have a broad impact on the work of others. A more modular code line means that people can more easily work independently with greater confidence that their changes won't have an unexpected impact on other code.

Another aspect to consider is whether you have a team structure where everyone on the team who is working on the same code line is working toward the same goal. If they all are, then it makes sense to work on the same code line. If your team has people working on different time horizons, then working on a single code line is harder to do.

Tying this back to the last question, a daily stand up is a great way to have the kind of communication that avoids code conflicts.

It's best to start with figuring out what development approach works best for you and having that drive the SCM approach you choose, but your SCM approach can also encourage a certain work style.

Dan Wellman: How does a project's release cycle affect this?

Steve Berczuk: Your desired release frequency most directly affects your approach to code-line management. If you release quarterly, for example, then you can get by with a model where you work on more branches targeted at different releases, and you can be less strict about encouraging that code builds and tests with each change. In some cases, having a model like that could lead to a situation where you just can't release frequently.

If you want to release more frequently, then you need practices that encourage frequent integration. The simplest way to do that is to work on a single main line and have the discipline to fix problems quickly so that the code line is never broken for long. You can also use a staged integration (or promotion) model, but that just delays eventual integration.

The more frequently you want to release, the fewer code lines you want to be working on, since each integration step between code lines can take time.

Dan Wellman: What common challenges do you see today with teams and their SCM practices?

Steve Berczuk: This is slowly changing, but there still are many teams for whom release management is seen as being over the wall from development, yet the SCM and release-management process affects so much of how developers work. This is analogous to how test and development were considered distinct before people started thinking about agile. While SCM and release management are skills in their own right, they need to be considered part of the responsibility of the development team and integrated into the development process.

As an extreme example, people have asked me about best practices for release engineers merging code. Maybe it's because I am primarily a developer, but it seems that having someone else merge changes seems like a bad idea. Trying to merge code while distanced in time from the change—and without understanding the context behind the change—makes little sense, as it's not always possible to understand a change without understanding the entire context. While the code should stand alone, it's hard to reliably capture things like the programmers’ intent and all the reasons behind a change. (Brad Appleton once wrote a pattern about this: “Merge Your Own Changes”).

So, probably the biggest problem is when developers don't think of SCM and build together with development, and when those responsible for release management and build are not integrated into the development process.

Dan Wellman: Are there any new developments in SCM that you've found particularly interesting or exciting?

Steve Berczuk: Interest in continuous deployment and continuous delivery is pushing the release process closer to development, which is good. And it's likely to drive tighter integration of SCM with build and issue-tracking systems. I hope that this leads to more of a concept of delivery workflow rather than build, commit, and deploy being seen as separate steps.

Dan Wellman: What question do you wish I asked you?

Steve Berczuk: The question that may be the least interesting on the surface to many—but which explains a lot about my perspective—is "How did you get interested in SCM?" The short answer is that I was fortunate to start my career with people who understood that release build, SCM, and coding skills are all part of the software development process that programmers follow rather than distinct disciplines. Working there, I learned how to avoid issues that seem to haunt most of the subsequent organizations I’ve worked with. Because of this, I felt that it was important to share a development-centric perspective on SCM. This ties very much into why I'm attracted to agile software development: Agile focuses on removing obstacles to delivery. SCM can help with that, too.

Dan Wellman: Thank you for helping me better understand the world of SCM. I enjoyed our discussion. Reflecting on this interview, I find it interesting that many of your answers bring up the social and interpersonal aspects of working on a software team. It sounds like you're saying SCM is not simply a software tool and a set of procedures to follow.

Steve Berczuk: If I can stretch a media metaphor (with apologies to Marshall McLuhan): If code is the message a team communicates with, the SCM process is the medium that communication occurs in. And it's hard to reasonably separate them.

Steve Berczuk is an engineer and ScrumMaster at Humedica where he's helping to build next-generation SaaS-based clinical informatics applications. 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.