Branching for releases, features, sub-features and environments

Question

I have gone through the TFS rangers guides before posting this.

I have the below requirement in our project:

1. Development of release 1 happens
2. It is deployed on Dev environment for integration and sanity test
3. If ok, then the code is deployed on QA environment
4. If ok, QA released code gets deployed on production.

Currently we have a code base in TFS under CODE, where developers code. The above is branched to DEV to mirror dev environment code DEV branch is branched to QA branch

In case a hot fix is required, then it is fixed directly on QA branch, and then later reverse merged to below branches.

This was fine till first time development, but I feel this needs to be re-structured to be better scalable for future release development.

Current issues:

1. need to plan to support future release 1.5 development
2. At the moment there are some features/fixes which may/may not go in current release. Developers just shelf it at the moment so that they can be unshelved in future. Issue is that with time, shelves become huge pain to merge as they do not have history
3. Sometime people work on big features on shelves for upto a week. Merging becomes a huge paint as till then those dozens of files have also been worked by a lot of people.

Keeping all the above in mind, i am thinking of redesigning our TS branching stategy as depicted below:

As per this approach:

• Development would happen on a dev branch such as DevRel1 branch only

• If a developer needs to work on a big feature, he would work on a branch such as Feature 1 branch, branched from Dev branch. On
  completion he would merge back to dev branch.

• For probably features, which may or may not go in this release, the develop needs to work on probably feature branched from main branch. As per final decision, it would be base less merged into appropriate dev branch.
• Code would be deployed in Dev environment from Dev branch
• Code would be deployed to QA branch from Main
• For release, main would be branched to a new release branch
• Hot fixes on QA happen on Main branch, and on Release happen on release branch. RI from release happens to main, and FI to dev branches happen in this case

Is this getting too complex? can it be simplified, does this look fine process wise, or does it need correction?

We are using TFS 2008 at the moment.

Answer 1

My advice would be to keep things as simple as you can. IMHO the main things to avoid are:

• Complexity confuses people. The more complexity there is, the more time it takes to deal with, the more merges you end up doing, and the more mistakes that are made. If you don't need a process then remove it.
• If you work on code in a branch, then you will necessarily need to merge code in the future. The longer branches live before they are merged the more difficult and time consuming the merge becomes.
• "Piggybacking" a hierarchy of branches on each other introduces the need to merge through multiple levels to get code back to the dev branch, which makes it time consuming to push a change from an outlying branch back into the main codebase.

So you should definitely use branching to support your dev needs, but try to keep your scheme as simple as possible.

We use a similar, but simpler, approach to yours. That is:

• We work on a Dev branch. Daily builds come off this branch for continuous QA.
• When a release "code freeze" is required, a Release branch is made. A bugfix can be made in either branch, but if required for the release it is always immediately merged to keep dev & release in sync. We try not to let releases diverge from the main branch at all if possible. We never have more than one release branch active at a time.
• When small features are developed, or where features can be developed without becoming "enabled" in the application or otherwise affecting the stability of the code, we continue to develop the code within the Dev branch. E.g We might use an #if condition to disable the code until it is safe to "activate" in daily test builds. This minimises the need for branching.
• When a large feature is developed that could potentially break the Dev branch, we work on a separate Feature branch. We try to plan the feature to minimise the time during which the feature/dev branches are allowed to coexist, and if possible stop developers working on related areas of the code while the feature is developed, to minimise the merge problems when the feature completes. If possible features are developed between releases to minimise the overlap (the number of concurrent branches).

Our other key strategies are:

• Use Continuous Integration, Unit Tests, Regression Tests, Gated Checkins and continuous QA testing to keep the Dev branch as stable as possible. Our aim is that any daily build "should" be good enough to ship straight to a customer. In reality there are occasional short periods (a few days) where that stability is lost, but most of the time when these happen we are still within a few days of having a releasable build.

• Defer making branches until absolutely needed. In TFS you can retroactively create a branch from any point in the codebase history. So when we are ready to start a release branch, we don't actually create the branch but just send the current release build to the QA department for testing. If they are happy with the quality of that build, it goes to customers as is, with no branch having been created. It is only when we need to fix a bug for that release that we actually create the branch (from the point in time where the original release-candidate was built, so we know it starts from the well tested code snapshot) and incur the (small) costs that entails.

As a side note, we also tried a Dev branch, with gated checkins to QA branch with gated checkins to Release branch, but this worked poorly (Primarily we found that it added a considerable overhead to all development. We like to check in frequently and the two extra test-and merge steps for every checkin are expensive. In the worst cases, if you delete, move or rename files in TFS it becomes very flakey and even simple merges fail - these are difficult and time consuming to sort out. We decided that merging in TFS is still not lightweight and robust enough to support this sort of approach unless you are prepared to invest a lot of time into managing the branches. On the other hand, if devs are careful with their checkins, there is far less need for such a "rigorous" approach. So we swapped back to the above lightweight approach, which increases the risks but minimises the need to merge - for us (with a smallish and disciplined/competent team) this approach works better.