Skip to main content

SCM Tool as Collaboration Tool


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.

Code Lines

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.


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 opposite effect, decreasing your velocity and making it harder for team members to work together. So while how a tool supports branching is important, it's more important to understand why you are branching, and if branching is as helpful as you'd like. As I explain in more detail in a article on TechWell:

Branches are helpful if the enable you to work more quickly than a single code line would.

To make this concrete, here are some examples of solutions to a "fix the release" scenario:
  • Use a Release Line: A common branching pattern is to create a branch when you release software, The Release line allows you to deliver fixes to the released software quickly without having to worry about the impact of new development work on the code. Most of the time a release branch is the right choice for managing changes to a release. There are alternatives, but each adds its own cost. 
  • Defer the fix until the next release is scheduled. This will only be a viable option if the problem isn't critical, or if the team releases software frequently. In many cases, teams don't release software frequently enough to do this. 
  • Fix the problem in the existing code base and release early. This can work only if you have a continuous quality assurance cycle that insures that your code is always ready for release, While many teams strive to do this, few are able to.
So, in many cases, the traditional Release Line pattern is the right choice. But it's good to be aware of alternatives.

Distraction

While branches can be useful, they have costs that you need to be aware of. Team Software development is a balance between integration and isolation. Branching can be a powerful tool for isolating change.

But be aware that not all changes are are isolated as they first appear. For example, much of the time when you fix a problem on released code, you will also want to address the problem in your new development code line. So by working on a branch you have created the need to do the same work twice. And the more branches you have, the greater  the risk of distraction, and reduced velocity.

Software configuration management practices and tools are part of a developer's basic toolkit. Like all tools, the right tool used correctly they can help you get your job done. The wrong one used without understanding can distract you from your goal.

Branching can help improve your velocity, but be sure to be aware of the reasons you are branching, and always ask your self if the branch will  deliver enough value to justify the cost. and always test and integrate frequently to avoid surprises.

Keep in mind that the real goal of an SCM environment is to help your team to work effectively.

Comments

Popular posts from this blog

Continuous Integration of Python Code with Unit Tests and Maven

My main development language is Java, but I also some work in Python for deployment and related tools. Being a big fan of unit testing I write unit tests in Python using PyUnit. Being a big fan of Maven and Continuous Integration, I really want the  Python unit tests to run as part of the build. I wanted to have a solution that met the following criteria:
Used commonly available pluginsKeep the maven structure of test and src files in the appropriate directories.Have the tests run in the test phase and fail the build when the tests fail.
The simplest approach I came up with to do this was to use the Exec Maven Plugin by adding the following configuration to your (python) project's POM.

<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>exec-maven-plugin</artifactId> <executions> <execution> <configuration> <executable>python</executable> <workingDirectory>src/test/python</workingDirect…

Displaying Build Numbers in Grails Apps

Being a fan of Continuous Delivery, identifiable builds, and Continuous Integration: I like to deploy web apps with a visible build number, or some other way of identifying the version. For example, having the build number on the login screen for example. In the Maven/Java world, this is straightforward. Or at least I know the idioms. I struggled with this a bit while working on a Grails app,  and wanted to share my solution. There may be other, better, solutions, but the ones I found approaches that didn't quite work they way that I'd hoped.

My requirements were:
To display a build number from my CI tool, where the number was passed in on the command line. In Bamboo, for example you might configure a grails build as
-Dbuild.number=${bamboo.buildNumber} warTo only change build artifacts and not any source files.To not misuse the app version, or change the names of any artifacts.To be simple and idiomatic.I realized that that Grails itself changes the application metadata (appl…

Motivation Visibility, and Unit Testing

I've always been interested in organizational patterns (such as those in Organizational Patterns of Agile Software Development). I've recently found myself thinking a lot about motivation. I'm now reading Drive: The Surprising Truth About What Motivates Us and just finished Rob Austin's book on performance measurement. Being the parent of a three year old, I'm finding more and more that "because I said so, and I'm right" isn't too effective at home. My interests in motivation are closely related to my interest in writing software effectively. Writing software is partially a technical problem about frameworks, coding, and the like, but the harder (and perhaps more interesting) problem is how to get a group of people working together towards a common goal. Agile practices, both technical and organizational, build a framework which makes having the right amount of collaboration and feedback possible. But there's a bootstrapping process: How do yo…