This project has moved. For the latest updates, please go here.

Branching strategy for systems with lots of frequent releases

Jun 25, 2010 at 4:46 PM
Edited Jun 25, 2010 at 4:49 PM

Hi there I have a question about the best branching strategy to follow when you have systems with very frequent releases.


Here is a bit of background info. We're currently using TFS 2008 and we're planning on setting up a 2010 environment in the next couple of months. We've been working from the Branching Guidance 2 for a while and it fits most of our scenarios quite well, although we've had to amend the guidance slightly. As an organisation we don't usually have more than one version of a product so we don't need to support "product 2008" and "product 2010" we just have "production", also the software is used typically hosted on our own infrastructure so the idea of Service Packs goes away. In most cases we've adopted the Standard branch plan but we're using a "hot fix" branch in place of "Service Pack" as we still need to get quick fixes in to live independently of the regular dev cycle, this seems to work quite well in most cases.

We made the decision to organise our team projects by "System" and we have about 50 team projects and there are probably another 70 or so systems still in VSS which will be migrated to TFS over the next 12 months

Some of our systems release code in to production several times a week and on occasion several times a day! It's in these situations where we are feeling the pain. Currently we create a Release branch for every release that goes in to production and this means we have a lot of release branches, which makes Source Control cluttered and understanding the branches is quite difficult for our CM and Development communities. We try to mitigate this by using folders, so we would have a "test" folder where the release branch is created from main, when the code is made live we move the branch in to a "live" folder and when the next release goes live the old release branch is moved in to an "archive" folder. This makes things a bit easier to understand however integrating changes made in a release or hot fix branch back out to all the other branches that require the code is quite confusing.

There are broadly 2 scenarios that we need to address to streamline our TFS usage.

Scenario 1:

Product  A is a web site which is updated several times a week. The projects that make these updates to the system are often run independently of one another and the release order is fluid and often changes towards the end of the development lifecycle.
In this particular case there can be up to 10 concurrent projects, each of which have their own development branch. Typically all of the code in this branch can be thought of as being a release. Although we could use the main branch to consolidate the code from the separate projects in to a single release we would still have the requirement to be able to manage separate releases on the same day / week as one project may be seen to be more business critical than another and if a relatively unimportant change failed it shouldn't affect a more important one. This is as much a cultural problem as a technical one.
The changes made by the different projects are usually to different areas of the system but there are some core files / components that are high contention. The changes made by the different projects can vary in scope to relatively minor code / web page / config changed to complete re-writes of sections of the system, data changes are unusual. As far as testing the changes, testers are usually allocated to a project and the majority of testing is done in isolation of the other projects. The testers are mainly testing that requirements have been met and that the code developed by the project is defect free. There is a final stage of testing that is done in a "live-like" environment. If several releases are due to go on the same day then the different project teams would expect to test the changes in a single environment. Other projects going live immediately after them would also be expected to integrate the code into their dev branch and test for any issues.
There are some quality gates in place to check that the code meets certain standards (code reviews, unit testing, code analysis, Tester sign off etc) before the code can be released however occasionally there may be a need to release code that hasn't met all of the standards.

Scenario 2

Product 2 is a system which is being developed as a programme of work and the release order is usually static so release 1 goes before release 2 etc. There are 3 dev teams and each of them have a development branch. The programme also needs the flexibility to release code very frequently in the same manner as Product 1. The main difference between the products is that in this case there is a fixed number of development teams and the release phases are co-ordinated by the same set of project managers so things should be better planned.

I'm not 100% sure about the way testing works in this scenario but I'll contact one of my colleagues and get more information.

Our main problem seems to stem from the frequency of releases and our current process which dictates that we create a new branch for every release. We have a requirement to be able recreate a build from a point in the past and branches make this very easy. However the number of branches and how we manage this is the issue.