?
Solved

TFS 2010/2012 Branching Guidance

Posted on 2014-02-07
2
Medium Priority
?
429 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
2 Comments
 
LVL 23

Accepted Solution

by:
wdosanjos earned 2000 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

Become an Android App Developer

Ready to kick start your career in 2018? Learn how to build an Android app in January’s Course of the Month and open the door to new opportunities.

Question has a verified solution.

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

Many of us here at EE write code. Many of us write exceptional code; just as many of us write exception-prone code. As we all should know, exceptions are a mechanism for handling errors which are typically out of our control. From database errors, t…
This is a fairly complicated script that will install the required prerequisites to install SCCM 2012 R2 on a server.  It was designed under the functional model in order to compartmentalize each step required, reducing the overall complexity.  The …
Integration Management Part 2
Whether it be Exchange Server Crash Issues, Dirty Shutdown Errors or Failed to mount error, Stellar Phoenix Mailbox Exchange Recovery has always got your back. With the help of its easy to understand user interface and 3 simple steps recovery proced…
Suggested Courses
Course of the Month9 days, 18 hours left to enroll

569 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