Why we branch when we release

Jonk asked me to write up this portion of a dog and pony show I do from time to time.  It’s the bit where I pretend to be a source control expert and tell other people what to do.  I’m usually pretty successful, but only because I am quick with a witty response while I compose a more suitable (read plausible but not necessarily correct) answer.

Today’s subject, “why we branch when we release” is some thinking around the problem – How do I release code and still have the ability to move forward on the next feature and yet not lose the ability to patch the release if I need to.

Let's break this down to the component requirements so we can be sure to address them all:

• a simple source control process around releasing code
• easy ability to continue development of new code after releasing
• ability to patch on released code and re-release without worrying about new development, after the release, will be included

With those requirements in mind let's discuss what the "normal" development process looks like from a source control perspective.  You check-out a code line to your local system, your sandbox, you make some edits to the code files on your local drive and then check them in (Commit).  If your any of your fellow coders have made changes in the interim you "pull and update" (Update) and get the latest version of the source code in your sandbox.  Usually you're working on the TRUNK, the main line of development.

So, you code away for a sprint (I presume you're doing agile by now) and its time to release.  For the sake of simplicity let's pretend that you're batting 1000 and there are no bugs nor defects found by QA - congratulations rockstar! So what do you do to keep your source control clean and tidy?

This is really simple, so try and follow along, when you're ready to release you create a Release Candidate Branch off the trunk. Let's call the branch "Version1_Release".  This snapshots your code at the designated point and allows you to make changes to both the version you released (the release branch) and continue development on the TRUNK.

To paint a scenario, picking up where we left off, You created "Version1_Release" and pushed that code to production.  Two weeks go by without issue, and because you're such a great agile shop, you start doing some serious refactoring on the TRUNK - I mean really destructive stuff that require database changes you've split one business object into two and combined three others. The code on the TRUNK today is nothing like what is in production.  Now for one reason or another your software mahirs (to mahir: to go from 0 hits to massive amounts of traffic overnight, see Mahir Çağrı) and you didn't really do any load testing.  So two weeks later you have the problem of needing to do performance tuning on the software you currently have in production.

Good news for you, you branched so you can easily SWITCH to the "Version1_Release" branch and make the changes you need. Check in the changes to the branch, release the branched code internally to let QA do the requisite load testing and then release it again.  You saved the day, you fixed the software and you didn't have to try and figure out how releasable the current TRUNK is and rush it out the door.  Finally, you just have to merge your changes on the patch to the TRUNK - if you want to.  But it should be a simple merge since you really should be trying to make only minor changes when patching right?

Let's review our requirements and see how we did. 

• Simple process around releasing code:  Seems pretty good on this requirement.  We didn't do any double check-ins, we didn't have to do any massive merges and we know that we have a leading code edge (HEAD) for both our whats-in-production code and our new development.

• Easy ability to continue development: Well this is a no-brainer, by branching at the designated release point people working on the TRUNK will have nothing different to do.  They just keep pulling updates and committing advancing the TRUNK and adding new features.

• Ability to Patch on released code and re-release without worrying about new development, after the release, will be included: Easy, by branching the two lines of code share a common ancestry and remain associated to one another for merging they are distinct and can be dealt with entirely separately or not.

As far as my experience, I've worked with Visual Source Safe (never again - not enough money on the planet to make me go back), CVS and Subversion.  I am presently working with Subversion using SmartSVN as my client (I've actually got the full license $79 - it's worth it).  Occasionally I use TortoiseSVN - this is what most of my colleagues use.

Back when I was using CVS I read Essential CVS (Essentials), by Jennifer Vesperman.  While the bulk of the book is directly about CVS, there is a great section in the chapter about Tagging and Branching (Chapter 7 around page 74, some of the book available on Google books ).  Actually, 9/10ths of the dog and pony show I've given twice now comes from her book and specifically that chapter.

I don't really care if I've convinced you of anything, because you're the one suffering if you haven't fully leveraged source control.  I really like CVS and used it for several years.  I've moved on to Subversion which has more or less, in my mind, taken the torch from CVS.  Both CVS and Subversion have served me well. I've never lost source code - as I had with VSS - and I was always easily able to get in and make what I want happen.

And now some instructions:

• If you're using Visual Source Safe, stop, migrate now to Subversion - you are okay and people do like you.
• If you haven't already, setup a test repository where you can experiment with branching, tagging, merging etc. with impunity without risking your precious source code.  I've always tested out an operation I've never done before on a controlled environment.  This is really how I was built my confidence with the systems.  This is also a great way to train your co-workers about what source control can do for you.
• Check-in, check-in often (with check-in comments), update frequently.  Integrating as you go beats the nasty three day merge with multi-devs
• Use source control on every project, even if you're the only developer.  It's freedom people, freedom to delete, to change, to experiment.
• Finally, source control doesn't make up for communication - talk with the people you're sharing it with have a strategy and be disciplined about sticking to it.