TFS Branching and Merging Strategy - Multiple Applications, Multiple Development Teams, Monthly Releases (but need to support out of rels changes too)

Question

We are looking for guidance regarding Branching and Merging for TFS and multiple applications (some are COTS; some internally developed) with multiple development teams. Note that we currently utilize monthly release windows but are going to quarterly. We also need to be able to support eFixe and non-release development efforts (ie: regulatory changes that have to be implemented outside of a window). Based on current research we are focusing efforts on research of the following 2 options:

Option 1) Release branching per major application where each application would have MAIN, RELEASE and PRODUCTION branches (the PRODUCTION branch would support an eFix branch which would support eFixes and off cycle changes).

Options 2) Release branching for entire organization - MAIN, RELEASE and PRODUCTION branches would contain ALL applications.

Answer 1

A number of helpful branching suggestions here:

Visual Studio Team Foundation Server Branching and Merging Guide

WRT to your question my view is

Option 1) Individual application release branching

The is if your applications does not have too many if any dependencies on each other.

Pros:

• Builds would be quicker
• More flexibility to Cherry pick deploy components
• Better for Continuous integration builds as you can build and deploy little and often
• Sign off and lock indivdual applications based on your quality quality gates
• Easier to redeploy critical fixes
• Merges smaller and possibly more frequent

Cons:

• Possible management overhead for maintaing builds/deploy scripts
• If there are application dependencies could introduce risks when cherry picking components
• Require solid deployment framework for maintaining the assembly versions and labels.
• Multiple deployment asset resources will be involved when deploying (instead of 1 deployment package)

Options 2) All applications release branching

Pros:

• Easier to identify the version of all apps at any time,
• Can deploy using Teardown and full deploy,
• Less build and deployment scripts to manage
• Lesse deployment asset resources to mange.
• Easier to track/visualise release level merges/changesets

Cons:

• Builds may take longer
• Less release flexibilty if an application is not fit for purpose or contains bugs after code freeze/sign off
• Harder to cherrypick deploy components
• Production critical fixed may take longer to get rebuilt and deployed
• Rollback is all or nothing depending on the deployment framework
• May require full regression tests for minor fix deploys (depending on the QA controls)