Solved

TFS 2010/2012 Branching Guidance

Posted on 2014-02-07
2
419 Views
Last Modified: 2014-02-10
Dear Experts,

I am searching for some guidance on how to set up branches in Team Foundation Server. We are using TFS 2010 at a customer site and the customer is planning on upgrading to TFS 2012 soon. The customer has nearly 120 independent applications. Each application
is independent and most of the applications are small utility type of applications. There is an ongoing effort to consolidate a few of these applications in order to improve re-usability. But each application supports one of the three major COTS products and so it
would be unlikely to reduce the the number of applications significantly.

I looked at the guidance provided on Codeplex (http://vsarbranchingguide.codeplex.com/).

Looks like it would be good to start with the simplest approach provided on Codeplex (Basic Single Branch Plan or Basic Dual Branch Plan). All the scenarios on Codeplex assume that the source control contains smaller number of products.

My concern is - I do not want to branch out each of these independent applications into three child branches - Main, Dev and Release. May be that's the right way but it just seems odd to have that many parallel branches (one of for each application) and have additional child branches (dev and release) for each application 'main' branch. Also, I have advised the customer is that they do not have to branch unless they need an isolated development area.

What kind of branching strategy do you recommend for this type of scenario (codebase with large number of independent applications)?

 Thanks for your help.
0
Comment
Question by:shekhar_shashi
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
2 Comments
 
LVL 23

Accepted Solution

by:
wdosanjos earned 500 total points
ID: 39844318
It depends on the lifecycle of each of your applications.  If they evolve independently (different versions are released at different times), then it makes sense to have different branches for each application.  On the other side, if they evolve together (different versions are released at the same time), then it makes sense to have a single branching  (Main, Dev, and Release) for all applications.

Branching is all about managing/isolating change, if your customer has to maintain multiple versions concurrently (new development/testing, production code), then it makes sense to have multiple branches.  If not, then a simpler branching strategy will work.  Note, that these needs may evolve over time, and the branching strategy can/should be changed to accommodate them.

I hope this helps.
0
 
LVL 3

Author Comment

by:shekhar_shashi
ID: 39848226
Great explanation. Thanks.
0

Featured Post

Forrester Webinar: xMatters Delivers 261% ROI

Guest speaker Dean Davison, Forrester Principal Consultant, explains how a Fortune 500 communication company using xMatters found these results: Achieved a 261% ROI, Experienced $753,280 in net present value benefits over 3 years and Reduced MTTR by 91% for tier 1 incidents.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

For those of you who don't follow the news, or just happen to live under rocks, Microsoft Research released a beta SDK (http://www.microsoft.com/en-us/download/details.aspx?id=27876) for the Xbox 360 Kinect. If you don't know what a Kinect is (http:…
I have put this article together as i needed to get all the information that might be available already into one general document that could be referenced once without searching the Internet for the different pieces. I have had a few issues where…

726 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question