A branch is what happens when your development team needs to work on two distinct copies of a project at the same time. For example:
Suppose your development team has just finished and released version 1.0 of your product. As you released version 1.0 you still have new cool features that need to be integrated in the new version of your product (version 2.0), but on the other hand you need to support your customers that are using version 1.0 of your product. The problem is that everybody on your team was focused on version 1.0, but with the support of this version and the development of version 2.0, you now have to lines of development you need to support.
The no nonsense solution to this problem would be that you make a copy of your entire repository and start the development of version 2.0 on that copy. It’s a solution, but not a perfect one. This approach becomes disappointing in situations where you want to apply a change to both trees. For example: every time a bug is fixed in the 1.0 maintenance tree, you probably also want to apply that same bug fix to the 2.0 development tree. As the fix becomes more complex, the more time it takes to apply the fix twice on both trees.
To resolve this time consuming work, source control tools support a feature which (in TFS) is called ‘branching’. Basically you fork your source code into two trees of source code called branches with the same history and the possibility that each of the two branches can evolve on its own. Because both branches have the same history a source control tool can track the changes between these branches and make it possible to merge changes between the two branches.
‘A branch is like a puppy…’
Don’t create a branch unless you are willing to take care of it. The mechanics of branching in TFS are simplified to a single right click followed by a branch command. However, the total cost of branching is paid by reduced code velocity to the main branch, merge conflicts and additional testing can be expensive. So before you make a branch, be sure to know how the branch will support the development project.
So how do I determine the costs and benefits (ROI)
The costs
The main cost of a branch is in the time and potential for mistakes to be made during merges. Because eventually you have to perform one or more merge operations. Yes, the tool will make that merge easy, but you still have to do it.
The benefits
The greatest benefit is that branching enables parallel development by providing each development activity for the current release its own self-contained snapshot of needed source, tools, external dependencies and process automation. Such a self-contained snapshot effectively enables each development activity to proceed at its own pace, without taking any dependency on another.
But remember, a branch is like a puppy… if you create a branch with the intention of never merging to or from it, and never making changes to it, then you should not be creating a branch.
Once you begin thinking of branches in terms of cost and benefit I hope most teams will find a productive middle ground that gives them the right amount of branching to achieve their business goals.
A branch plan
The best way for creating a branch plan is to keep it simple. This is done by avoiding additional releases in the beginning (i.e. Service Packs and Hotfixes) and slowly begin the transition from a simple plan to a more complex branch plan as your product an business needs evolve into a more complex system of costs and benefits.
The situation described at the beginning of this topic (product version 1.0 that needs support and the integration of new features in version 2.0) is a perfect maintenance and development example for having a branch plan. But there are two common reasons to want to have a branch plan.
Sometimes a subset of your team needs to work on something experimental (i.e. a proof of concept or proof of technology) that will take several weeks. When they successfully finish, their work will be folded into the main tree, but in the meantime, they need a separate place to work.
The final reason to want to have a branch plan is when you want to use a dev-test-prod methodology. This is often called ‘code promotion’. The basic idea is that your code moves through three stages, ‘dev’ (products that is in active development), ‘test’ (products that is being tested) and ‘prod’ (products that are ready for a release to your customers). This model can work effectively but especially in larger companies where the roles of the team (developers, testers, operations) are very clearly separated.
Conclusion
Be afraid of branches, but not so afraid that you never use the feature. Don’t branch on a whim but do branch when you need a branch.
2831e096-fa08-48c7-ba67-2e719e4b5517|0|.0
Microsoft Team System
microsoft, team system, vsts, tfs