This project has moved and is read-only. For the latest updates, please go here.

TFS 2010 and Branch Security

Jan 21, 2011 at 7:01 PM

Our company has tried to follow most of the suggestions that has come out of the Branching Guides since we have never used Branching and Merging before. The hardest part of this whole project was determining how we should divide our applications into TFS Team Projects.   I wish there was a lot more examples out there on how to break down your Team Projects from other companies other than companies that release software.   That is another discussion though.

We started out by creating a MAIN branch in all of our TFS Team Projects.  We then moved all of our solutions and applications that we knew was currently running in production over to that branch. This we locked down completed so only our Quality Assurance group and a few IT adminstrators for TFS could do anything in the MAIN branch ( This mainly was for Merging  and Branching).   Ww then needed a Branch for when we moved from the Development phase into a UAT phase.  This branch within the TFS Team Project would then serve as a place that code would be built to our UAT environement for QA to test and End-Users to test functionality.    This branch is secured that Developers can edit and checkin changes but cannot MERGE or Branch from.  Then there is the DEV branch where all of the initial development is done from and testing from Local and Development Environment happens. Security for that is Developers can Merge to, check-in check out about everything. 

Our company also has lots of changes going on simultaneously to a TFS Team Project by multiple development teams.   So in our setup we create a seperate QA branch for each functionality that is being done,  and a corresponding DEV branch.  We have one single MAIN branch for each TFS Team Project. 

I think our processes work pretty well when moving from DEV123 to QA123 and then to MAIN.  

When DEV123 is ready to be Merged to QA123 developer creates a WORKITEM for QA team to Merge to QA123 and start testing - along with EndUsers. Once ENDUSERS are completed testing they either create a BUG if something does not work and the DEVELOPER will fix that BUG in the QA123 branch.  If no bugs exist and end-User signs off on request it is then Merged into MAIN.  

This is where our problems are - in the MERGE.   When Merging new changes in Main back to QA lets say QA456.  Since the QA team is the only area that has the security to MERGE when they get a Merge conflict they then must bring the developer in to determine what the want to do with those conflicts.   If the Developer is also working in new fucntionality in DEV456 QA456 branch would then be Merge into DEV456. 

With the how the permissions are setup in TFS,   I cannot setup a different permission for developers when moving from DEV's to QA's to MAIN than from moving MAIN to QA's to DEV's.

I know from a developer standpoint everyone would say that this is hindering their performance by not giving them permissions to MERGE.   But, what we have seen if we do not put security on Merges we are not completely sure that the code in production is production code. 

Any suggestions would be VERY helpful.  We have been in production with TFS about a month now and we are close to having a revolt on our hands.   We have never really had a good Source Control product with processes before.  We used VSS and locked each application on checkout.  This caused a huge bottleneck on developement.  




Jan 21, 2011 at 8:17 PM

With respect to Team Project organization, the VS ALM Rangers are publishing an article in MSDN Magazine on this topic (Feb 2011 issue).

In our branching guidance, we create a Main branch for stabilizing the next release. After this is stabilized we branch main for release, and lock the release branch down. It seems you are using Main the way we recommend using the Release branch. And then it seems you are adding a new branch for UAT and QA. This what Main is used for in our Guidance.

There are a couple of key points here. I do not recommend creating a branch for testing that is owned by QA. The development team should own the Main and Development branches. If QA needs to start testing... I recommned you deploy code to QA (not branch for QA). By this, I mean you would either build Main and deploy to QA or build a dev branch and deploy to QA.

The QA, since they do not understand the code, should not be responsible for merging. Merging should be owned by the development team - people that know the code and can best resolve merge conflicts. Further, the decision when to do a merge should be made by the Dev Team. The Dev team may look for QA to certify the code, that is passes the QA quality gates, but then the Dev team should do the merges.

I think this approach would mitigate the issues where QA needs to bring in the Developer to resolve merge conflicts. QA should never being doing the merges in the first place.

In our model, your QA456 branch would be Main. This is the branch for stabilizing code. When QA wants a new build... build Main and deploy a new build to QA.

If you want to test a single Dev branch independently of other Dev branches, build that branch and deploy to QA.

Having a QA branch AND a Dev branch for every Dev Team simply increases the merge effort and merge conflicts by an order of magnitude.

Deploy a branch to QA, fix the bug in the branch that is deployed for testing. If the bug is fixed in Main, do regular merging from Main to each of its children Dev branches.

If a bug is fixed in Dev, it will get merged to Main when the decision is made that the Dev branch is ready to be integrated, shared, or released. This prevents Main from becoming destabilized.

I recommend not giving merge permissions to QA at all, and not giving merge permissions to every developer. You should designate technical leads or senior developers and give them merge permisssion.

Bill Heys
VS ALM Ranger