Efficient TFS branching strategy advice

Question

Our company (internal projects) used version control (TFS, now 2015) for simply keeping an audit trail of released code - I have brought in the use of branching and merging and its completely changed the way we look at bottlenecks in the development pipeline and has generally been well received, but now I am looking for the next step.

Our code consists of one large piece of software and several other accompanying business applications.

We have four environments we keep up at all times, and our 'pipeline' is like so.

Developer does work locally.
Pushes code to a 'Development' environment (so we can all look at the code, see how well it integrates in the environment e.t.c)
When testing is ready we push to 'Test' - this is code that has been approved to be moved up the pipeline and therefore the environment is a lot more stable than 'Development'.
Next, we pass it to the UAT server, which is essentially a mimic of the live server, to be as stable and representative of a live release as possible. Code approved to move here is NOT frequent.
Finally, production environments.

Now I simply took the approach of having a branch for each environment, allowing for easy compares, for people to quickly grab the source and whatnot, and to see the progression of the codebase up the chain.

MAIN -> STAGE -> TEST -> DEV

This is one single, linear line, and we can simply view the history of the MAIN branch to see all the different released builds.

From the dev branch we splinter off into our local branches, and any hotfixes come directly off the UAT branch.

This works for us - but it works in the sense a procedural program could work - it may not be the most effective approach. I'm just very curious as to whether there are better ways to do this, and after reading loads of stuff online I feel like people don't split their branches by environment but I don't really understand how that works better? Even though it is a pain to merge four times to release some code (although most of the time it is a rather slow pipeline, we have weekly releases).

Any help much appreciated.

score 3 · Accepted Answer · answered Mar 21 '16 at 05:51

You are correct when mentioned that the more complex the branching strategy the more overhead to maintain.

But if the situation demands there are not escaping. If you have not gone through the branching strategy document by ALM rangers for TFS, please take a look. It should help you.

I think the strategy you are following is not an linear branching but rather the one in the below image. In a more complex enterprise software the branching strategy boils down to this.

thanks, I have seen the visual diagrams but not noticed the pdf's. I'll have a read now! — aspirant_sensei, Mar 21 '16 at 09:44

score 2 · Answer 2 · answered Mar 21 '16 at 02:58

I think it's a lot of overhead to maintain different branches for each environment as you rightly mentioned above (especially the number of merges). The simplest branching strategy is the one shown below (similar to what we use):

               Main
             |     |
             |     |
            DEV  Release

The development would happen in the DEV branch, once it is ready for UAT we merge it into MAIN and then create a Release branch. You can use the DEV branch for the next release development at this point and all the bug fixes for the current release will happen in the release branch now. The Release branch will be used for the PROD deployment as well.

As for whether this would work for you or not will depend on your specific needs but 80% of the projects I worked with uses the above branching strategy.

Efficient TFS branching strategy advice

2 Answers2