New article on Ranger’s Branching in upcoming MSDN Magazine.

After a few years hiatus, i am returning to the world of *published author*. My next article will be published in the February 2011 issue of MSDN Magazine ( ) The topic will be *Visual Studio ALM Rangers Branching Guidance for Team Foundation Server (TFS) Team Projects*. My co-author is Willy-Peter Schaub, also on the VS ALM Ranger team at Microsoft.

In addition to this blog, you can download the Ranger’s Branching Guidance at:

Feel free to post questions or suggest new topics for the next release of the Ranger’s Branching Guidance in the Discussions Forum for the Ranger’s Branching Guidance on Codeplex. You may also post comments here on my blog.

Bill Heys
VS ALM Ranger

Comments (1)
  1. In our Scrum team we used TFS 2010 since its first beta in 2009, and love it.

    1/ we experimented one workspace for the entire 3 branches (Dev+Main+Prod) {such as the Tailspin Toys examples}. However, sometimes trying to check-in within a solution, TFS 2010 presented by default other changes from other branches – which is, to me, really dangerous (apparently in TFS 2008 we don't have that behavior). Moreover, if we work in a hurry, on many branches at a time, we forget on which branch we really are, hence could check-in wrong changes [I know Brian Harry have this user story listed on his product backlog, as a low priority].

    ==>  As a result, we opted to a more tedious approach: 1 workspace per branch. What are your recommendations??

    2/ Per Branch, we have 20 different independent projects, and hence more than 20 TeamBuild Definition (=20 + other extra ones), which works really great in terms of quality (Gated checkin + UT +  automated MSI…) !!.

    ==> However, having 3 branches, we have more than 60 Build definitions. Do you have any best practices on this too ??

    Thanks a lots for all this work,


Comments are closed.

Skip to main content