Thursday, February 21, 2013

Are all your changes included in the next release?

I'd like to share one technique I've used with teams to help error-proof their branching to verify the next release will include all their changes. This technique only applies to the "One Branch" strategy since a single code line will always contain all the changes.

Error-proof Branching Strategies

  • One Branch (2 code lines) - main (of default) and release (or stable)
  • No Branches (1 code line) - main (or default)

The main error that occurs with branches is that developers forget to apply their changes to all branches. For example, a hot fix needs to be made to the release code line and the development code line to makes it in the next release. Like most errors, the developers aren't malicious and telling them to "do a better job next time" won't improve their behavior.

One highly effective technique I use with teams is to run a script once a day to validate that all changes made to a release branch have been applied to the main (or default) code line. Since this happens daily, any merge conflicts are minimized.

In this example using Mercurial, this batch script is called from a Jenkins job that runs once a day. If a commit exists on the release branch that hasn't been merged to the default branch it will fail the build. I hope you find it useful.

Branching Strategies


I've stumbled across many creative and interesting branching strategies during my career. I'm going to categorize the branching strategies in to two categories: Error-prone and Error-proof.

Error-prone Branching Strategies

  • Branch per release per environment based on previous release
  • Branch per release
  • Branch from a previous release
  • Branch per environment

Error-proof Branching Strategies

  • One Branch (2 code lines) - main (of default) and release (or stable)
  • No Branches (1 code line) - main (or default)