Do you know when to branch in TFS (aka TFVC)?
Rules to Better Branching And Builds|a6fc3dc2-af4d-4526-a729-d5ff20a6a78f
v6.0
Posted at
16/03/2017 5:15 PM by
Brendan Richards
Rule Intro
One of the most controversial issues developers discuss is when to create branches and how many you should have.
Keep things simple:
- Have the team develop on the one branch. It is fantastic as there are no more merging hell.
- Have that branch called "master" if using Git and "main" or "trunk" when using TFS or SVN
Beware of smart bloggers giving the wrong advice :-) as many smart people like creating branches e.g. http://blog.hinshelwood.com/archive/2010/04/14/guidance-a-branching-strategy-for-scrum-teams.aspx. Even Martin Fowler says there are a number of issues related to merging that lead us to try and minimise the number of branches that we work with in his article on Feature Branches.
The quintessential scenario you need to support is that emergency "Hey we have a security hole on the site and Hanselman has just tweeted it!"
In that case you need to potentially update all of your branches and perform deployment, which can be quite tiresome.
The better way is to use OctopusDeploy which relives developers from having multiple branches because you only have to worry about building on one branch and deployment can be done automatically to multiple environments. Octopus provides more secure, feature-rich environment which makes it very easy to deploy and promote builds between environments.
-
- Figure: Good Example: Manage deployments to multiple environments, view deployed versions.
{AEEEC9FA-6D78-4682-838D-091A3347CA28}
Do you feel this rule needs an update?