TFS 2010/2012 Branching Guidance

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.
LVL 3
shekhar_shashiAsked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
wdosanjosConnect With a Mentor Commented:
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
 
shekhar_shashiAuthor Commented:
Great explanation. Thanks.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.