Freigeben über

Sample branch plan for concurrent hot fix, service pack and v-next work

  • Artikel

Below is a branch plan that I've used before that enables servicing a released product with hot fixes, a cumulative service pack (SP) and enables next version work in main and the development branches.  This is also simplified version on the branch plan used for Windows development at Microsoft but could also be useful in your organization if you have similar servicing requirements.

 

imageBranch planning, like many aspects of application lifecycle management, does not have canned solutions that work for everyone.  I'll step through the details of this branch plan and hopefully parts of this will apply to your project and a starting point for your own solution may emerge.

Goals

This branch plan enables concurrent hot fix, SP and v-next development.  It also ensures that changes can be checked into on branch and merge into branches of future releases. 

A by-product of this plan is that you should see fewer regressions from "lost" changes and reduced merge conflicts since changes are checked into one branch.

This post does not go into much detail on check in policies, quality gates or build frequency.  For that information you may want to start with the branching guidance on codeplex.com or look for later posts here in those areas.

Definitions

These definitions are used in the graphics for this branch plan.  The definitions I provide below are a bit more generic than the official MS servicing definitions.  Hopefully these broader definitions will make this branch plan apply to more situations.

  • Development branches - child branches of main where developers work on the current on future versions on your product.
  • Hot Fix - these are specific fixes required to unblock a specific customer blocking issue.
  • Main - this is the junction between the development and production branches.  For most organizations this is the "golden" branch that should be very stable.
  • Production/release branches - child branches of main where servicing (i.e. hot fix and SP) check-in's are made.
  • RTM - release to market, this is the branch that has the sources for your final release.
  • Service pack - a cumulative package of hot fixes and updates targeting a previously released version on you product.
  • V-next - the next version of your product.

 

Release vehicles

The release vehicle is how code leaves your organization.  For any branch plan to work you must define precisely the different ways that code leaves your org and gets to a customer.  In this example we have 3 release vehicles.

  1. Major release (RTM)
  2. Hot fixes for a major release
  3. Service packs for the major release

Once the release vehicles are defined you build a branch plan around these that enables code to be checked in once and merge back to main.

Branch plan in action

From development to main there should be regular forward (FI - parent to child) and reverse (RI - child to parent) integrations.  Once the code in main has reached some objective measure of release quality (e.g. bug count, test pass %, preview feedback, etc.) then it is time to create the production/release branch for this release.

The key to this branch plan is that the SP, Hot fix and RTM branches must be created in order to assure the parent child branch relationship is maintained.  

In TFS the physical layout of the release branches would look like this.

$/project
      $/project/development/dev_team1/source (branch from main/source)
      $/project/development/dev_team2/source (branch from main/source)
      $/project/development/dev_teamX/source (branch from main/source)
  $/project/main/source
      $/project/production/V1/SP/source (branch from main/source)
          $/project/production/V1/HF/source (branch from release/V1/SP/source)
              $/project/production/V1/RTM/source (branch from release/V1/HF/source)

If the spaces format correctly, you should see that the production branches SP, HF and RTM are children of each other.  In the production branches the further from main the branch check in policy is usually more restrictive. 

Once the production branch plan is created main and the development branches move on to "next version" work.  In this example we will call this V2.

Any changes for the V1 release happen in the appropriate branches based on the specific criteria below.

  • Ship stopping bug fix for v1 RTM - check in to production/V1/RTM (mark this branch read only after release)
  • Hot fix for v1 release - check in to production/V1/HF
  • SP 1 work - check in to production/V1/SP
  • V2 work - check in to your development branch

Changes should be RI'd in from RTM->HF->SP->main only.  This will ensure future releases are regression free as fixes will integrate into the next cumulative release (i.e. all hot fixes will be merged into the next service pack).  Do not FI changes from main to SP after the initial release branches are created.  An exception may be for merge specific change sets as needed for a HF or SP release.

This plan also supports n service pack releases and hot fixes for those service packs by branching from the SP branch.

  $/project/main/source
      $/project/production/V1/SP/source (branch from main/source)
          $/project/production/V1.1/HF/source (branch from production/V1/SP/source)    <-V1 SP1 hot fixes here
              $/project/production/V1.1/RTM/source (branch from production/V1.1/HF/source)  <-V1 SP1 release here
          $/project/production/V1.2/HF/source (branch from production/V1/SP/source)    <-V1 SP2 hot fixes here
              $/project/production/V1.2/RTM/source (branch from production/V1.1/HF/source)  <-V1 SP2 release here

Conclusion

This is a specific branch plan that enables concurrent hot fix, service pack and v-next releases.  Each branch is associated with a release vehicle to give the developers checking in a clear map of where their changes should be checked in depending on what release they are working on.

This plan also allows for a single check in to have a clear merge path to main to reduce regressions and merge conflicts.

Also, having a strong association between your branches and the release vehicles will keep the whole organization aligned on very specific releases and expose work that is not focused on a particular release.

If you product has similar release vehicles and servicing requirements then this plan may be a good start point for you. 

 

Reference

TFS branching guidance https://www.codeplex.com/BranchingGuidance

Microsoft servicing terminology https://support.microsoft.com/kb/824684

Comments