TFS Branching


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

ken hanseAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Anil GolamariCommented:
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:
Alexandre SimõesManager / Solutions ArchitectCommented:
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.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
ken hanseAuthor Commented:
all posted answers are very good and constructive
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft SQL Server

From novice to tech pro — start learning today.