Isolating and Integrating Parallel Feature Teams working on Separate Overlapping Releases

Customer scenario:

How should I isolate (and integrate) changes when working with:

• • 3 parallel efforts (two parallel development efforts, working on separate releases of the product and production support)
  • Production(version 2.0) with the need to issue hotfixes on then current production version
  • Development Team 1, working on the next minor (Feature) release (version 2.1). New minor releases every 4 weeks
  • Development Team 2, working on the next major release (version 3.0), planned for production in 1+ years

I am using the Advanced Branching Plan (with Concurrent Hotfix, Service Pack, and Release branches).

Requirements

• • We need to release hotfixes on the current production version (v2.0), without consulting with project teams which greatly slows things down)
  • We need to do feature releases in parallel with long running projects.
  • We do not want to merge these features directly into the development branch for the next major release (Development Team 2) This is seen as a serious project-risk.
  • We plan to release V2.1 sometime in the next quarter
  • We plan to release V3.0 sometime in the next two years

Questions from the customer:

• • How can we  release (minor) features on our product when other project teams working on a long-running projects for the next major release see these features as added risk to there project/test plans.
  • Should I frequently merge RI my project changes into MAIN (even if project runs for 1+ years)
  • How should I create a new feature branch from MAIN while there are already several RI's from other running DEV branches. (Branch by what ???)
    New features of our software always result in heavy discussions with other (isolated) project teams. While they see them as added risk and they always want a complete change-freeze while their projects run.  Only hotfixes to production are allowed.
  • This is because new features will be integrated into their dev-branches because these will be live way before the project will go live.

We are using TFS 2010 and VS 2010

My suggestions:

Use a variation of the standard or advanced branch plan. Both of these provide for sustained engineering (hot fixes) on current release in production (vCurrent) while simultaneously allowing development to proceed on the next release (vNext).

As we point out, the main difference between the standard branch plan and the advanced branch plan is the added branch on the release side in the advanced plan to support Service Pack and Hot Fix sustained engineering to the current release in production.

On the development side, I recommend adopting a pattern such as this:

In the preceding branching plan, development branches are created as children of the Main branch. Although new minor releases of the product are released on a monthly basis, multiple development branches are required since the development effort for some releases must begin before the iteration begins.

For example, in the preceding plan, Dev Team 1 begins work on release v0.1 (which is released at the end of iteration 1. At the same time, Dev Team 2 begins work on release v0.2. Since they need more than four weeks to complete their work on v0.2, they begin development during iteration 1 but release their changes at the end of iteration 2. This branching plan, therefore supports multiple parallel, overlapping development efforts.

Key to success with this plan is to ensure that Main is used to stabilize only one release at a time. During iteration 1, Main is used to stabilize v0.1 (blue). During iteration 2, Main is used to stabilize v0.2 (red). During iteration 3, Main is used to stabilize v0.3 (green). It is important not to comingle changes by merging into Main from parallel development on different releases (major or minor).

Any development branch can (and probably should) accept regular merges from Main (forward integrations – FI) – perhaps on a daily basis. If the development team working on a major release chooses not to accept merges from Main, this is their choice. At some point, presumably they will want to integrate changes from minor releases (for example v2.1) into their ongoing development (v3.0). However, in your case you indicate the development team for version 3.0 (the next major release) would like to proceed as if there is a code freeze in effect. This may or may not be a reasonable constraint. Since, in your scenario, they will not be releasing their code to production for more than one year, it may be easier to accept changes more frequently rather than waiting until they finish development on the major release.

You will note, that in the preceding plan, new features are integrated with the current state of the code in Main by first merging (FI) Main to the feature branch (for example Dev Team1). Once this this integration builds successfully and is tested, it can be merged (RI) back Main. Changes from a development or feature branch should only be merged to Main when they reach a milestone and pass quality gates (ready to release or ready to share with other teams).

There are times, however, where it may be necessary to integrate changes (for example from multiple feature teams working on the same release) without merging them into Main. For this reason, it may be necessary to insert an integration layer between Main and the Feature Teams

In the preceding diagram, Dev Team1 has a single feature team and therefore does not need an integration layer. However, Dev Team2 has two feature teams working in parallel and need to integrate their changes without merging to Main. During iteration 1, Main is used for stabilizing v0.1. An integration branch is added between Main and the Feature Branches for Dev Team2. The feature teams for Dev Team2 can integrate their changes using this integration branch until Main opens up for v0.2 stabilization.