通过

Branching Strategies

  • 项目

Under Software Configuration Management, branching and merging are common features that help maintain stable code bases and scale the development effort by synchronizing parallel development. However, depending on the size of your product, the size of your team, your isolation requirements and your development cycle, parallel development can become quite overwhelming, so it's very important to define a good strategy for branching and merging that meets your needs. This isn't always straightforward, so here are a couple of guidelines I usually use to tackle this issue.

The first thing I try to find out are the isolation requirements for parallel development, how many development teams there are and what are the stabilization protocols (how many quality gates there are and how many different test environments there are where these gates are checked).

Having this information helps me to define the logical structure for the branching strategy as well as the physical source control structure to support it.

One thing I always have to look out for, is to make sure that the logical structure is applicable to the physical structure. For this I usually define a set of use cases that act as a model that I "run" on both the physical and logical structures to check if they are supported.

Here are a couple of scenarios I usually contemplate:

  • Fixes
  • Release Stabilization
  • Code Promotion

I try to check all of these scenarios, considering that a mix (or all) of them might occur simultaneously. Here's a possible scenario I try to work out:

"Imagine there's a team working on a new release of feature A, part of another team is working on a fix of a previously released version of their feature (feature B) while the rest of the team is working on the next version. In the meanwhile, a third team is required to release feature C to a new test environment for functional testing by end-users."

Some questions that I might ask for this scenario:

  • How many teams/features are there?
  • What should the physical structure of my source control repository be?
  • How many independent branches do I need to make this scenario valid?

The Branching Guidance by the P&P team is an excellent place for different approaches to these questions and many more.

So, what do I really look out for when defining a branching strategy?

  • Good Logical Structure
  • Good Physical Structure
  • Make sure the logical structure is applicable to the physical structure
  • Run a model on both the logical and physical structures.

Comments