Friday, August 30 2013
Keywords: TFS, source control, version control, Release branch best practices, hot patches, service packs, how to branch release branch off of main
Branching Main to create a Release branch that will handle hot patches and service packs in TFS
Often I get asked what would the best practices be for creating a Release branch.
The exact fashion in which you should opt to structure your Release folders should be decided on a case-by-case basis and not decided by one rule. If the Team Project in question holds info related to Customer Support, or Car Manufacturing projects, then maybe it could be organized by year, meaning by having folders such as 1999, 2000, 2001, 2002 etc directly under the Release folder.
In software development it is common to witness Release sub-structures organized by application version number, i.e. v1, v2, v3, v4 folders directly under the Release folder. Then under each of those parent folders you could place v1.1, v1.2, v1.3 etc folders and so forth. And finally under the lowest level sub-folders you would find the actual branches. Such structuring would keep your Release folder neat and unclogged. Note that you should only go to the sub-folder depth that makes sense... only if you think that you will have a high number of minor versions released.
But now that your Release folder is neatly organized, how would you contrive to create service pack or hot patches?
I have seen folks who kept a Release branch in its default writable state and kept modifying it over and over in the future...directly. They defend their case by stating that they had applied a "Release v1" label and that they would easily be able to branch the original RTM version out of the ever-changing v1 Release branch...
I do not recommend this option... for various reasons... one being that it is not clean, it is not neat!... secondly unlike c++ files or project files or any other text based files, some binary files are not being version controlled equally in all version control applications; so if you are keeping the dependent tools and/or documentations and/or DLLs in your projects, version controlling them is not as straight forward or trustable as the text files. Another reason for not doing so would be that certain actions or disasters or domain modifications or human errors could erase the history or labels by mistake. There are more reasons as well.
Another tactic would be to branch off of your v1 release to a new branch called v1.1 and do all your service-pack/hot-patch work in there. This is not a bad idea in general, and is very common. The caveat with this is that for peace-of-mind reasons the original v1 Release branch should have been flagged as READ ONLY in your version control app to avoid it from being mistakenly overwritten in rush-rush situations arising from those infamous hot patch creating adrenaline rush moments. Therefore any branch off of a Read-Only branch could intrinsically inherit its parent's Read-Only permissions. As a TFS Administrator, I have witnessed lots of frustration and confusion caused by this.
Another MAJOR flaw with the above solution is that if you want to port the changes from v1.1 back to Main or Dev branches... you would need to first merge v1.1 to v1, so that you could then merge v1 to Main... as you are obliged to travel the natural hierarchical path. But that is a major violation of a read-only v1 branch: first of all you are changing the RTM release (v1)! Secondly it's read-only and needs to be flagged back as writable. This whole system is wrong and should not be attempted.
Therefor my personal recommendation is to create a writable v1 branch... and immediately afterwards create a v1-RTM branch and tag is as Read Only. Now future hot-patches and service packs will be derived off of the original writable v1 and the changes could be ported back to v1 and then to Main then to Dev etc. Your RTM branches will remain untouched, and will never need to be modified. This is a true Win-Win situation for TFS Admins as well as Developers, both.
For the last 20 years I've been blessed with being a developer as well as an administrator, both. I have the responsibility to look at the IT world from both points of view. And although some Release branching topologies do respond to developers' needs, they don't equally satisfy company's or administrators' requirements. The world of TFS branching and organization is one such example in which most methodologies are derived from developers' point of views and cannot be fully backed up by administrator. However I find that the above solution does satisfy the needs of both parties.
Written by Ramin Haghighat