This project has moved and is read-only. For the latest updates, please go here.

Release vehicle structure

Jul 30, 2010 at 11:29 AM

We are in the starting fase of creating a branch structure for a small group of developers (10+).

In the tfs branching guide 2010 it is proposed to create a release tree from MAIN at the same time
or more advanced if needed (MAIN->SP->HOTFIX->RELEASE)

Is there any simple reason why this could a better release tree than i.e. what we are considering: MAIN->RELEASE->FIX

We are considering to branch out from the RELEASE branch, only when we have to fix errors in our production version.

When no fixes is needed we will not create the FIX branch.


Jul 30, 2010 at 4:11 PM


When we create the release tree, we create Main->Servicing>Fix>Release all at the same time.

There are several principles involved here. First, the Release branch is a copy of the code exactly as you ship it to the customer. This branch is often made read-only. You would never change or merge into this branch after it is created.

Second the Fix branch is where you would do POST release engineering. Generally the changes made here are for fixing specific customer issues and are not as thoroughly tested as service packs. However it is possible you may want to roll hotfixes up into a service pack. You flow merges on the release tree ALWAYS towards Main (Reverse Integration).

So hotfixes can roll up to the ServicePack branch (Servicing) where they can be more thoroughly tested and shipped to a broader customer base.

Then you would merge ServicePack changes up (RI) into Main.

Inverting this tree structure means you will not have a copy of what you actually released (the release or rtm branch)

It also means you have to merge back up through the release branch to bring a fix to main.

Finally, the incremental cost of a creating a branch is relatively low UNTIL you start making changes. Since Deltas are all that TFS stores. When you Branch A > B, B has no Deltas yet.

If you don't need a separate Release branch and HotFix or Servicing branch (for archival or auditing purposes), then just create one branch in the release tree that you use for fixing/servicing.

But if you need both, please create them in the suggested  hierarchical relationship. You will (I hope) thank us later.

Bill Heys
VS ALM Ranger

Aug 4, 2010 at 7:17 AM

Thanks for your reply; it now makes sense to me with the order of release tree branches.

We are a department developing .NET integration software for our company’s online production system. The production system has monthly releases on specified dates, and we have a number of environments (Development-> UAT -> Staging -> Production) where we can develop and test our software before it is released to production. Parallel development is a relatively new practice in our company, and not supported by all our platforms. But we are using it in our .NET development.

Is there an obvious branch structure in our case (i.e. monthly releases and four environments)?

Aug 19, 2010 at 5:39 PM

I like to reinforce the idea of separating development and release issues when designing a branching strategy.

Therefore I would like to divide your question into two parts:

  • What is a recommended branching strategy for monthly releases
  • What is a recommended branching strategy for developing a system that is tested in a number of different environments prior to release

With respect to monthly releases, we recommend creating the release branches at such time as the code in the Main branch has been stabilized and is ready for release. This presumes that you have some established quality gates that the system must pass in order to make the *ready for release* decision. Since you are proposing to do monthly releases (a typical agile process), you would create a new set of release branches each month. This approach isolates your proudction (released) code from the ongoing development. Your organization needs to determine how many releases to maintain. You may decide to only keep the current release. Or you may decide to keep current and one prior. Legal and other requirements may influence how long an archived release branch needs to be maintained.

 On the development side, I view the need to support multiple testing environments as more of a deployment issue rather than a branching issue. You mentioned having Development, UAT, Staging, and Production environments. For the development environment our guidance suggests isolating development from the main branch by creating one or more development (or feature team) branches. Depending on the complexity of your development, you may only need one development branch in addition to the main branch. Devleopers will have workspaces on their development machines to provide isolation from other developers on their team. Each developer will likely do unit testing on their own workstation.

At some point the code being developed by a team may need to be tested by a separate Q/A team. Rather than create a whole branching structure, I would recommend deploying the code to the testing environment(s) directly from the Developer Team's  branch. Once the code in a development branch reaches a level of quality, it can be shared with other teams. At this point the code in the development branch can be merged with the main branch for integration testing.  At this point, you would deploy the code from the main branch into whatever testing environments you require (UAT, Staging, etc)

Finally, as stated above, you would reach a point where you are ready to release.. the release branch is deployed to production.

Bill Heys
VS ALM Ranger


Aug 23, 2010 at 7:50 AM

Thanks for your reply.

We are considering to just create one branch in the release tree for fixing/servicing, as your suggest.
But we are looking at the pros and cons of reusing the servicing branch instead of creating a new one every time we start servicing a new release.

One pro we are looking at is: we do not have to remap our workspaces, when reusing the branch, which can be an advantage when considering tfs build.
One con we are looking at is: we loose the possibility to service the old release when overriding the branch with the new release.

Are the other pros and cons of reusing the servicing branch?

Aug 23, 2010 at 11:47 AM

In my view the inability to service the released code because you are reusing the release branch outweighs the other considerations. For this reason alone, I would create a new release branch for servicing each new release. You then decide how many prior releases you will support for servicing.

Bill Heys
VS ALM Ranger