TFS Branching

ken hanse
ken hanse used Ask the Experts™

Can any one demonstrate the best practise structure using TFS for DEV and Test and Prod environments?  

Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
All developers need to check-in their changes into trunk/dev branch only. As soon as someone check-in their code it is better to run a CI build (Continuous Integration) to make sure that new changes haven't caused any issue in existing code. If you are using TeamCity then you can add as many Unit tests as you want and be able to verify them after CI build is completed to make sure you are good with the latest check-in.

Once CI is good then you can push those changes into a Stagging branch where you can deploy your code to QA/Stagging area and have your testers do an end to end testing. After all, tests are completed and the code base is ready for production then it is better to tag this branch with the release date or any identification which we can use in future if you need to release a hot fix for specific release.  


Let's say you are planning to release something for March 2016 then below are branches that you can have for that release.

Dev branch: trunk ( all developers can check-in into this branch).

Code from trunk should be able to deploy to development branch for developers to run some tests. Before moving code to stagging/QA.

Stagging:  master (Code is ready for stagging area for QA testing). The code will be deployed to QA servers and handed over to testers for their testing.

Production: master_march2016_release ( You can name it something like this, it is better to follow certain naming convention within your team or firm to be consistent)

Note: Once you have deployed code to production, no one should access "master_march2016_release" branch anymore.

Best Practices:
Manager / Solutions Architect
Just to get this out of the way, I want to say that branching strategies have no strict attachments with TFS. This means that whatever branching strategy you may read that potentially is being used with Git, is also perfectly usable within plain vanilla TFS.

This said, and also knowing that TFS supports Git as it's source control repository, let's dig into my preferred approach that involves several branches:
You can have a look at an exact same approach that someone called Git-Flow

These are the branches that mark the milestones of your app, should always be used and their hierarchy should be respected.
Dev Branch
This is where all the current development code goes.
In a simple project scenario, all devs should checkin their daily code in this branch.

Release Branch
If you're doing SCRUM, this is where you put your code at the end of each sprint.
A release marks a state of your development process when something is ready to be packaged and eventually deployed.

Prod Branch
This is where you have your Production code.
You should never arrive here from the Dev Branch instead, you should promote something that is already in the Release Branch.

These branches are only used when necessary.
Feature Branch
When you have a bigger project and/or a bigger team, having everyone checking in the code in the same branch will become a mess.
Developers should checkin often, not only at the end of the features, and this can lead to people checking in incomplete code that will break someone else's environment.
To avoid these problems and still make sure that the code doesn't sit on the dev machine for days without being checked in, you can use Feature Branches.
These are branches from the Dev Branch and represent a single peace of functionality that is being developed.
The developer can checkin, out, revert, do whatever he(they) want(s) without impacting the main development branch.
At the end of the feature development process, the code is merged into the Dev Branch.

HotFix Branch
This is for patching production issues and is very very... VERY! useful.
The idea is that, when you have an issue in prod, you should fix it in the Prod Branch, not in the Dev Branch. Why? Well, I think it's quite obvious. After the prod deployment, development continued so there's no easy way to deploy your current dev state in prod without deploying a whole lot of other stuff that has been made.
On the other hand, fixing it in the Prod Branch will make that fix only available in Prod and not in Dev, potentially allowing the bug to come back to life in the next release.

In this case, what we do is create a HotFix Branch that is a fork from the Prod Branch.
Apply the fix code, do our tests and then merge this HotFix Branch with both Prod and Dev.

This branching layout gives you a lot of flexibility and for me is probably the best standard approach.



all posted answers are very good and constructive

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial