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

Branching and SAAS projects

Dec 22, 2010 at 11:26 PM
Edited Dec 22, 2010 at 11:30 PM

I work at what is, for all practical purposes, a dot com. We have a single production website that all of our customers use.  We have been working in TFS 2010 for a few months now and would like to optimize our branching strategy to remove some of our pain points with merges and releases. I have been reading the branching docs and, maybe I misunderstand things but I'm not sure what strategy best implements what we are trying to do. Let me breifly describe our setup and see what pointers you have:

  1. We do monthly production releases. Those releases consist of the entirety of the site.
  2. Unlike a typical agile shop, those releases vary in scope. For instance :
    1. We have  couple of developers working on an immediate need hot fix.
    2. we have many developers and testers actively working on our minor release going out next month (January). 
    3. Due to the scope no one has started working on the February release yet.
    4. We also have quite a few developers and testers actively working on a relatively large release going out in March. In addition to local workstation builds, there are Dev and QA environments set up for these folks to use.
  3. In addition to local workstation testing we have separate development integration environments and QA environments for each actively developed release.
  4. We have a compile-once model where the release gets compiled and put into our dev environment and then, rather than re-compile, we repackage the binaries with config files updated for the new environment. We use the tfs deployer project to handle this based on build quality changes.
  5. We have multiple feature teams (3 right now, will be going to 7 soon) working on different aspects of our product. I'm thinking of creating feature branches to allow them to isolate their work until its ready for regression testing.
  6. Currently we have 3 branches - we have named them "Future", "Next" and "Current" We do forward integration every successful dev build and reverse integration whenever a release goes into production. 
  7. Occasionally we create a feature branch for releases that can't go right into the future branch due to active development going on in future.

Things aren't extremely screwed up we are just wondering if there is a better model to handle our process. Any advice you could give would be great.

Dec 23, 2010 at 1:12 AM

Have you read the branching guidance? There are many approaches outlined in the guidance that might improve your process.

Perhaps you can help me better understand your branching strategy if you could map your three branches into one of the plans described in the guidance.

What are the relationships between your Future, Next, and Current branches. Why would you forward integrate between these three branches on every dev build if they are, in fact, separate development versions?

In which branch do you make hot fixes (Current?)

Does your *Current* branch map to the *Release* branch in our basic plan?

Does your *Next* branch map to the *Development* branch in our basic plan?

Do you have a Main branch for stabilizing the next release?

Bill Heys
VS ALM Ranger



Dec 23, 2010 at 2:04 AM
Edited Dec 23, 2010 at 2:04 AM

I read the guidance scenarios although this was recently. We had a TFS consultant in who set the branching up although he had some issues with how we work and I'm not sure that we ever had anything either of us could agree on. here is how things break down for us:

  1. Current would be where we make hot fixes
  2. Next is active development for next months release. developers check their code in there, we have a CI build running.
  3. Future  is active development for the release after that.
  4. Any additional releases are managed in feature branches

I get that this doesn't seem to fit any of the scenarios but I'm really not sure how to implement something that would fit what we are doing.

As far as forward integrations go, my understanding is that forward should happen quite frequently as long as you are reasonably comfortable with the quality of the code being merged and reverse integrations happen less frequently - basically when releases are delivered. Maybe I have the terms reversed. 

Here is what I don't get about the main branch - my understanding is code isnt checked directly into it,  it only happens via merges. Given that we never really saw what, given our development model, the purpose would be to it. For us, when the code gets compiled for dev a build number is assigned to that release and those artifacts are re-used all the way up to production. Also our work items are updated with that build number so that our business side folks can determine what build a bug or enhancement was completed in and whether or not that build has made it past qa testing.  so its not like we would recompile the code for the QA environment based on a merge. Its kind of an audit point for us.

Dec 23, 2010 at 2:40 AM

Thanks for this information. I still would like to better understand the branch relationships. If you are doing forward and reverse integrations, you must have a parent / child relationship between branches. For example in our guidance, Main is the parent ot each of Development branches and is also the parent of the Release branches. Main is our stabilization branch, where the next release is stabilized before it is released. Again it sounds like Current = Release and Next = Development. There are many benefits to having Main. In our branching plan, if you have multiple Development branches (Feature Branches) they would all be children of a common branch (Main). These development branches would, therefore, be siblings of each other. Code is developed and checked-in to the Feature branch(es) - with CI builds. At some point the code in a Feature branch reaches a state where it passes quality gates and is ready to either release or share with other Feature teams. To integrate Feature1 Team with Feature2 Team, since these are siblings, you would merge Feature1 to Main (RI), and then merge it to the other Feature Team(s) (FI). While development proceeds in the various feature teams, Main can be uised to stablize the code that has been shared (or deemed ready to release). You should be doing daily builds in Main with Forward Integration from Main to Development branch(es) on each good build in Main. You would deploy the code from Main to the QA environment for testing. Main, therefore, allows development to proceeed in the Development branch(es) while it is stabilized in Main. A given Development branch may not always be in a state that it is ready for deployment to QA - it might not be stable at certain points in time. But Main should be more stable and capable of being deployed to QA at any time. When the code in Main is ready to be released (passes quality gates) it is branched to Release (your Current).

If you don't have Main, then what would be the common parent to your various development branches. How would you integrate changes from one feature team to another, without doing baseless merges. Where do you test this integration?

If you don't have Main, then what would be the common parent to your Release branch(es). Many organizations need to support multiple releases (vCurrent and vCurrent -1). Then need to be able to ship hot fixes and / or Service Packs for one, two, and sometimes more releases in production. I realize that this is not your model - you only have one release in production. But that simply means you are a simplification of a model that supports one or more production releases. I prefer a model that works for both the simple and the complex case. The basic branch plan achieves that, I believe.

Bill Heys
VS ALM Ranger


Dec 23, 2010 at 5:06 AM

On your statement ". I realize that this is not your model - you only have one release in production." yes that's true but we do have a kind of strange situation below production. Right now QA is testing 3 software releases at the same time. They are testing some hot fixes that are going to be dropped into prod in a week or so (maybe, it just might end up getting shoved into next months release, you know how it goes). They are testing next months release which is largely a collection of low-level enhancements and bug fixes. They are also beginning to test code releases from the quite large release going in in March. Oddly enough, what they aren't testing yet is the February release because the scope is so small development hasn't even started yet.

The whole thing is sort of a strange compromise of our need to drive innovation fairly rapidly to market new customers while coping with an overall customer base (Large Banks, fortune 500 companies) that, once they get on, would prefer we not have that much change  because it means a fairly large training effort on their part. That is, unless, of course, its their bug fix which they want yesterday :)

Dec 23, 2010 at 4:40 PM
Edited Dec 23, 2010 at 4:42 PM

I think I have something that works for us, this is my idea let me know if you see any issues with it.


  1. Scrap the current branch structure
  2. Implement a standard branch scenario with dev branches broken down by release and feature team to allow them to make changes to multiple releases at the same time.
  3. Reverse integration happens from a dev branch to main when regression testing starts. 
  4. Reverse integration from main to service pack and Release branches for hot fix purposes when a full release has been pushed to production.
  5. Builds for the dev branches would be optimized for quick turnaround, building only the projects they are working on.
  6. Integration builds would be full builds. These would be the ones we would track for audit purposes. 
  7. Code would be reverse integrated
Jan 15, 2011 at 2:26 AM

This blog may give you some insight as to my recommended approach:

Bill Heys
VS ALM Ranger



Jan 17, 2011 at 4:01 PM

Thanks for all your help on this. I am proposing this to our dev manager and I expect we will be adopting it.