Steve Berczuk is a software developer, writer, and experienced practitioner of software configuration management (SCM) and agile software development. He is a co-author of the book Software Configuration Management Patterns: Effective Teamwork, Practical Integration, contributed to the book 97 Things Every Programmer Should Know. Last year, he interviewed Dan Wellman about test-driven development. In this installment of From One Expert to Another, it’s Dan’s turn to interview Steve about the ins and outs of SCM.
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.