Wednesday, October 21, 2015

Branching strategies–Blog series

There is a lot of discussion going on about branching strategies and how a good branching strategy looks like.

My preferred branching strategy has only 2 rules:

  • Rule #1 – Don’t branch
  • Rule #2 – Go read Rule #1

Branching should be an exceptional case as every branch introduces a merge cost (and this cost can be high!). Of course in reality, it’s not always that simple.

With the renewed vibe around Continuous Integration and DevOps, a good branching strategy is crucial. One blog series I recommend reading is Version Control Strategies:

This series of articles describes a taxonomy for different types of Feature Branching – developers working on branches in isolation from trunk – and how Continuous Integration is impacted by Feature Branching variants.

  1. Organisation Antipattern: Release Feature Branching – the what, why, and how of long-lived feature branches
  2. Organisation Pattern: Trunk Based Development – the what, why, and how of trunk development
  3. Organisation Antipattern: Integration Feature Branching – the what, why, and how of long-lived integration branches
  4. Organisation Antipattern: Build Feature Branching – the what, why, and how of short-lived feature branches

2 comments:

Kat said...

Hi Bart,

From your other posts it seems you're stuck with TFS for version control and for build - and in this setup I agree that branches are more pain than they're worth.

If you are able to persuade your team to upgrade to using Git within TFS 2015 and TeamCity for your builds you will find that a great deal of the pain of branches goes away.

Our system is to create a new feature branch for each backlog item in the sprint. By swarming stories we never have more than a couple of branches active at once and each branch lives for, on average, a day or two. TeamCity is quite happy to produce builds from a number of different branches, and with the right build script you can make it easy to identify where a build came from. When the devs are happy, they open a pull request and the testers will complete the pull request when they are happy that the acceptance criteria have been met.

It works really well and the team love it. The best thing is that we can always tell where a bug came from, and the appropriate developers have to fix it before the story can be completed!

Bart Wullems said...

Hi Kat,

I spend most of my time with TFS Version Control although I prefer Git whenever possible. With small branches I don't have any issues but problems start to appear when (feature) branches are living too long. In that case using Git or TFSVC doesn't make any difference as merging remains painfull. The pull request model from Git is a nice one but not always appropriate.

Bart