A few weeks ago I had the opportunity to give a virtual talk at a product launch for an SCM Tool vendor. The theme of the talk was basic branching strategies, and preparing for the talk led me to reflect on what Brad and I wrote in the SCM Patterns Book. This post is based on those thoughts.
When Brad Appleton and I wrote Software Configuration Management Patterns I wanted to focus on how to use Software Configuration Management and Version Control to improve productivity and collaboration. In many organizations SCM processes, procedures, and policies are focused on stakeholders other than those who rely on the system most: developers.
A good SCM process can help you to work better as a team, and help your team be more agile. An ineffective one can slow down development, and be an obstacle to progress. Likewise the tools you use, while secondary to the decisions about the way you work, can affect how effective your SCM process is.
Tools are important. A good SCM tool helps you work more effectively as a team and allows you to focus on your work and not the mechanics of the SCM process. But the process needs to come first to use SCM effectively. Here are some brief thoughts on what I think are the core issues to consider when designing an SCM process.
While there are many aspects to Software Configuration Management, the first concept that comes to mind for many is version control. Developers commit changes to a code line, and update their workspaces from a code line. The main role of an SCM process is to facilitate integration, and you want commits and updates to be frequent to avoid complicated integrations.
Frequent commits also give developers the full benefit of having a history of their work so that it is easy to revert to a known state when a coding experiment goes wrong. So you want processes and policies that encourage frequent integration.
The simplest SCM model is to commit changes into a single code line. Working on a single code line is simple in some ways. But it requires discipline to keep a single code line, with frequent commits, stable.
A code line where people have practices such as tests and a discipline of pre-commit builds in place, is an Active Development Line. Not every team can maintain this discipline. And even for those who can there are legitimate reasons to work on more than one code line. Once developers realized the challenges of working on a single codeline, they quickly become interested in the way a tool supports branching.
The first question people often ask about a tool is how it supports branching, this question is best answered in the context of understanding why you want to branch. Branching is a technique for enabling parallel development. When you branch you create code line that is a copy of its parent and it can evolve independently. A Branch allows you to work on variation of the code without affecting or being affected by, changes in the parent code line.
The ability to work in parallel can be an effective tool for enhancing productivity. It can also be a cause of bottlenecks and frustration. The difference between the two results depends on whether you follow branching patterns that address the problem that you are trying to address.
Branching can be a very useful mechanism for making your development process more effective if you do it the right ways, with the right tools, and for the right reasons. A poorly applied branching strategy can have the