MT

Many patterns exist out there for software configuration management, none of which are a panacea for all of your SCM problems. Things get especially complicated when you have more than one team working on features for your product. To start off the discussion, I'm going to start with a simple branching strategy that works well for a single team, and then show what can happen when you introduce multiple teams into the mix.

Before discussing the different patterns, I'd like to clarify how to think about branches. Branches are inherently evil if they're abused (and it's easy to do so). Each time you branch, you have more to maintain, more to merge, and usually more headaches. So when you decide to branch, you have to come up with a good reason to justify the headaches. These justifications can be represented in the form of policies for the branch. A branch policy is a set of statements that define the rules for checking into that branch. If a set of branches have the same policy, then they generally should be merged into one branch. There are exceptions to this, such as code isolation, but is true for the most part.

A Basic Strategy

A simple branching strategy for a development team could be the following:

• Main
• Code builds
• Only potentially releasable code is checked into this branch.
• Code passes all unit tests.
• Release
• Only regression tested, released code is checked into this branch.
• Only bug fixes related to the released version should be checked in.

The idea is that each developer works on user stories and only checks code in when the branch policy has been satisfied. Once all users stories in the Main branch are ready to be released, a branch is created from Main. Developers continue to work on the next release out of the Main branch while maintenance fixes are checked into the release branch. At some point before the next release, the bug fixes in the release branch are merged back into the Main branch so they'll be present in subsequent releases.

Let's discuss what happens when we scale this to 4 development teams. Right away, team's will notice that the build breaks more often. Why? Because instead of 6 or 7 people checking in code, we now have close to 30 people checking in code. As humans, we make mistakes and now those mistakes are going to happen more often and when it does, it hurts everyone. Another thing that you'll start to see is fewer check-ins from developers. The reason is because every time someone checks in code, everyone else has to pull it down and merge. When this happens, you have to retest what you were working on to make sure it still works, which takes more time.You'll also see the opposite, more check-ins (but ones that break the branch policy). A small number of developers will get tired of merging code and will be more prone to check in code that hasn't been fully tested. What's needed is some sort of isolation among the teams so that each team will be less likely to interfere with another team.

Multi-Team Strategy

The pattern that I've experienced that works well is for each team to have their own branch, and then have an integration branch to integrate the features being developed in the development branches.

• Team
• Code reviewed
• Code builds
• Code passes all unit tests
• Main
• Only potentially releasable code is checked into this branch.
• Must be regression tested
• Release
• Only regression tested, released code is checked into this branch.
• Only bug fixes related to the released version should be checked in.

Team A and Team B are both working on user stories. Team A finishes story A.1 and merges that code into the Main branch. Later, Team B finishes story B.1 and before pushing it to Main, pulls down the latest code from Main (which contains A.1). Once the Team B branch is in sync with Main, the code is merged into Main. The cycle keeps going until the end of the iteration. When it's time to cut a release, the Release branch is branched from Main. Bug fixes found in the release are fixed in the Release branch and merged down into the Main branch, which will eventually make it's way into the team branches.

With this pattern, each team is free to check in and work as the did with the first pattern. In fact, the branch policy is more relaxed because all of the QA and integration is done in the Main branch, which allows for more intermediate check-ins into the team branch. As is with developer workspaces, the more you pull down from the Main branch and merge, the easier it becomes.