Releasing software on time requires a process that's thought out, scheduled, and consistently executed. It starts with a branching strategy, follows with a release strategy, and ends with good cross-department communication and documentation through the use of a bug and task tracking tool. Today we're going to focus on two of those steps in detail- branching and releasing.
- Git Tutorial for Learning Source Control or a basic understanding of Git
We've adopted the semantic version naming convention put forth by semver.org. Please review this naming convetion and return to this page when you're finished. Now, consider 0.1.0 the first production release of our software.
The top area of the chart indicates that we are on a weekly release schedule. That means that no matter what, we are tagging a new release on the same day at the same time every week. We also cut our release candiates for the following release that same day we're tagging the current release. More on this later. You don't want to get into the habit of delaying releases. Releasing should be a small, manageable, routine procedure. Coupled with continuous integration, you have a better chance of catching bugs earlier this way. You'll want to release on a wednesday or a thursday and in the middle of the day. This will greatly reduce the chance of you having to put fires out late at night or on weekends.
The Master branch
The only time we ever branch off of master is if there's a live issue found and we have to create a hotfix branch. So barring hotfixes, you should only be merging release candidates into master at the end of your cycle.
To create a release candidate, you pick a day to branch off of develop. In our case, we cut a release candidate the same day we release. So let's say it's wednesday and we're ready to release 0.2.0. We take our existing 0.2.0-rc.1 branch, merge that into master and tag it 0.2.0. That naming convention indicates that this is a major release. We then also create a release candidate branch for 0.3.0 off of develop at the same time, essentially freezing a version of develop where it is for QA. Now while QA is spending this week testing 0.3.0-rc.1, we're continuing to develop what will essentially be 0.4.0-rc.1 for the following week. We repeat this process week after week.
We only branch off of develop when developing features. The naming convention is engineerinitials_featurename. We can stay on a feature branch for as long as necessary. On the day we're ready to cut a release candidate, we simply branch off of develop where it is at that point in time.
The Master branch
In our case, the client has found a bug in the first release that requires a patch, so we're forced to create a 0.1.1 branch, merge that back into master and retag the master branch 0.1.1. We also have to merge the 0.1.1 branch into the rc branch that had been frozen prior to finding the bug and the develop to make sure the patch makes it into all releases and not just the patched release we just tagged. If you don't understand the difference between a branch and a tag. So barring hotfixes, you should only be merging release candidates into master at the end of your cycle.
During this RC phase, QA finds one bug, but we patch it up with a 0.3.0-rc.2 branch and merge into master, tagging it 0.3.0.
- Learning Source Control with Git and SourceTree: A Hands-On Guide to Source Control for coders and non-coders
- Version Control with Git: Powerful tools and techniques for collaborative software development
- Learn Version Control with Git: A step-by-step course for the complete beginner
- Version Control with Subversion: Next Generation Open Source Version Control
- TortoiseSVN 1.7 Beginners Guide