Captures ideas around branching and releasing strategy.

Branch to release model

I have used branch to release for many years for small, to moderately sized teams, though I think it can be applied to many team sizes and complexity of project. This setup has worked for me in 99% (leaving 1% off in case I forgot somewhere it didn’t make sense) of my projects. I will use git as my jargon, but can be applied to many different VCS’.

Some assumptions about this approach are:

• You write automated tests.
• You take huge projects and dice them up into small, testable chunks.
• You only commit to master if it is ready to go live.
• You communicate with your committers.
• You know what you are changing.

Arguments against it:

• Sometimes I want to commit something without it being ready
  • Your problem is too big then. Dice it up.
  • You are writing too much code for one commit.
  • You need to take the time to write tests.
  • Implement parallel dev or having feature go “in the dark” / be configurable.
• Others won’t write tests or break my code.
  • Communicate more.
  • Do code reviews.
  • Weed out the offenders.
  • Fix your culture, not put in more process.

In this diagram you are committing to master (M), and the second commit you branch (B) 0.1. That gets deployed, tested, and approved. You then tag (T) as 0.1.0 and release that. You start to dev more on master and even branch 0.2 to prep another release. Bug is found in production against 0.1.0. If bug still exists in M, you fix the bug (BF) there with tests and cherry-pick (CP) the commit to 0.1 and have it flow down the same stream resulting in 0.1.1 tag like:

If the bug doesn’t exist in M, you fix in 0.1 with tests, commit, wash, rinse, repeat.

If cherry-pick cannot be applied cleanly, you fix in both, with tests, tag and release. This should be a lot less likely if you are dicing up the problem into small chunks and committing small changes.