Last blog, I talked about a simple branching strategy. Today, I’ll tackle a slightly more complex scenario. A while ago, I ran into a client (small group) that already released a version of their application into the field. Things were running smoothly for a couple of weeks, developers were busy working in the DEV branch on the next version release. Suddenly, a major bug in the release was found and they needed to apply a patch to the deployed application. In other words, they needed to create a hotfix for a released version.
Here is a branching strategy I like to use for hot fix scenarios. First, I would still have a MAIN branch which holds the latest stable version of the code. From MAIN, I would branch to DEV. This is the branch developers use to work on the latest and greatest (next version). Like the simple branching scenario, changes are merged to the main branch where QA performs their tests. When the code is feature complete and the quality is acceptable for a version release (v 1.1, v1.2 etc), I would branch from MAIN to a hot fix branch, and then branch from the hot fix branch to a V1.1.0 branch for archival purposes. I do this whether I need a hot fix or not. I do this just in case I will need to write a hot fix.
Inevitably, I get someone asking me, “Why do that? Isn’t it expensive to branch”. The answer is no. If you use TFS as your source control, branching is actually very cheap. TFS only stores the differences (and some meta data for each branch). TFS handles branching very efficiently. Granted, what shows up on your hard drive (if you map your workspace to all the branches) will be copies of the code, but what is stored in TFS is just the differences.
So now, features for the next version are being worked on in the DEV branch. If you need a hot fix, make the changes in the hot fix branch. When the hot fix is finished, branch from the hot fix to another archive branch. If you need to bring the hot fix changes to the current (next version) code base, merge your changes from the hot fix branch to the MAIN branch. Take care of potential merge conflicts as well as potential code breakage here, and when finished, merge the changes from MAIN into DEV.
Here is how I would lay out the code in source control/file structure:
$/Project/
$/Project/Main
$/Project/Main/(Source code for application)
$/Project/Development
$/Project/Development/(Source code for application)
$/Project/Production
$/Project/Production/V1.0
$/Project/Production/V1.0/Hotfix
$/Project/Production/V1.0/Hotfix/(Source code for application)
$/Project/Production/V1.0/V1.0.0
$/Project/Production/V1.0/V1.0.0/(Source code for application)
$/Project/Production/V1.0/V1.0.1
$/Project/Production/V1.0/V1.0.1/(Source code for application)
$/Project/Production/V1.1
$/Project/Production/V1.1/Hotfix
$/Project/Production/V1.1/Hotfix/(Source code for application)
$/Project/Production/V1.1/V1.1.0
$/Project/Production/V1.1/V1.1.0/(Source code for application)
$/Project/Production/V1.1/V1.1.1
$/Project/Production/V1.0/V1.1.1/(Source code for application)
There are circumstances where you might need to have the ability to roll up hot fixes into service packs. If you know you will need to roll up hot fixes into service packs, then you would use the same branching structure, except when it’s time to branch for production, you branch MAIN to SERVICEPACK, immediately, from SERVICEPACK to HOTFIX, and from HOTFIX to an V1.0.0 SP 0 archive (read only) branch. If hot fixes need to be done, developers work in the hot fix branch. Changes are merged back to the SP branch, and from the SP branch, back to main, where code breaks and merge conflicts are fixed, and then the changes are merged to DEV. Service Pack specific code is done in the SP branch, and when it’s time to release a service patch, you would branch from the SP branch, to a HOTFIX branch, and from the HOTFIX branch, to a read only V1.0.0 SP 1 archive branch.
As you can see, this will greatly increase the complexity. However, if you need to support a released application with hot fixes, actively work on a cumulative service pack that includes all approved hot fixes, and you need to be concurrently working on the next major release, then this branching strategy will accommodate and facilitate an organized and planned migration path for all features which minimize the chances of merge conflicts and code breakage.
Enough on branching for now… next time, support for multi-feature/multi-team development!!