Branching Strategy for Test Environment

Question

We will be starting a new project this month. The project will be 1 year and production deployment will only occur towards the end of the project.

We will be doing iterative development (1 month per iteration), so this means we will drop features to Test environment at the end of each iteration for QA testing.

Our branching strategy is:

1. Trunk - All development will happen on trunk.
2. Feature Branch - Branches off trunk will be created on a per need basis for development of large features which could potentially be breaking if done on trunk
3. QA Release Branches - At the end of each iteration, a branch of trunk will be created. This branch (which includes a version number) will be released to Test environment. All critical and blocking bugs found in this version will be fixed on this branch and fixes will have to be merged to trunk. Non-critical/trivial bugs will not be addressed on the QA release branch and will only be fixed in trunk since the QA release branch will be thrown away after the end of the next iteration where a new release branch will be created off trunk.
4. Production Branch - this will be the latest QA release branch at the end of the project. This will be tagged and all production bug fixes will be on this branch and merged to trunk.

Is this a correct branching strategy? Is there anything else that we've missed to consider?

We're using SVN.

Answer 1

Your branching strategy looks really good to me. I have done the same strategy in the past and it works fine. Draw it up on a whiteboard and get all your devs to understand it so that people do the right work in the right branch. Teach and explain to everyone the switch command and get everyone to doublecheck the branch that they are working on. (Or alternatively just check out the entire repo... depending on your code size :) Remember... svn revert is your best friend!

Personally I prefer one person to be the "merge/branch" person (with a few backup people as reserves) to ensure that everything is kept under control and consistent. Let that person become your SVN guru and you'll be away.

A few other helpful hints:

• Encourage frequent SVN updates and SVN commits. Every day is preferable.
• Cross branch merges should also be done every day, or alternatively whenever a bug is fixed. Do them early and do them often! (you'll get good at it real quick).
• Get a good diff tool - beyondcompare is ace. The standard tortoiseSVN one... not too good.
• Don't check in stuff that changes upon compilation (like your output directory)
• Try to clean up your repo before you start branching (get rid of files that don't need to be under version control - things like external libraries etc). The smaller your repo, the better
• Changes to your Production branch and QA branches should be as small and short as possible - don't start refactoring code there, just fix the bug.
• Make sure you branch from the top level of your solution - and if you have a DB I hope you've scripted all of your DB stuff (like stored procs or triggers)

Also tell people not to move folders around unless it's strictly necessary. This will make your merging much easier :) (Don't do what I did, launch upon a massive directory restructure halfway through a huge change to trunk which screwed up all of our merges... I was pretty popular after that).

Answer 2

It sounds like an idea that might not work.

Maybe take a look at this link for some inspiration: GitHub Flow This is the way github is using it's version system. Even though they use git instead of svn I would argue that the ideas behind their decisions will hold nevertheless.

The (imho) most important parts of this blog post regarding versioning:

• master / trunk is deployable or - even better - deployed
• development happens only on branches
• merging happens only after review (maybe you can place QA here)

This way you get stability. Let me explain why. You need some base to branch off. Now if this base is not the very best you could do and the ultimate instance of everything then it doesn't really make sense to do so. If you branch from trunk while others work on it you will see bugs they introduce that happen to not be found or fixed yet. So likely integration tests (and anything above) may fail on you even though you're not the cause, drastically increasing the amount of debugging and frustration.

Moreover you will have lots of work keeping your 3 branches (trunk, QA, production) in sync. This will likely lead to confusion. I can almost guarantee you to loosing track at some point in time if you do not enforce this with automation.

I would suggest going the way GitHub is going. You can then tag which version you send to QA to have a reference when communicating. Even better could be having QA tighter integrated in the feedback loop as stated above. I strongly suggest using a CI system like Jenkins if you haven't considered using it yet. That way you minimize the round trip time between check-in and feedback and you can enforce coding rules, run static analyzers for error checking and so on.

Disclaimer: The git flow happens to work only if you don't want to fix bugs without introducing new features. If you want to do this your approach might be better suited.

Answer 3

Your branching strategy strikes me as quite reasonable. We have pursued a similar strategy at my company and it has worked well with us.

One slight difference is that we do pre-release QA fixes on the trunk because it prevents us from having to merge back and we haven't really had a problem with developing new features while fixing defects. This does give QA a bit more of a moving target in terms of what they are testing, so how workable this is depends on how tightly integrated QA is with the dev team. It works well for us because we have a pretty integrated team and because we are on a fast iteration schedule. We do have a separate branch for each release so that we can patch the production environment while still building new features on the trunk, but that doesn't seem like it will be necessary for you until later when you start releasing beyond QA.

There are a couple of additional recommendations that I would make:

1. Encourage frequent check-ins. This is especially useful if you have many people developing on the trunk. It will prevent developers from getting out of synch with what others are doing and reduce the potential for conflicts. Make sure that there is explicit guidance about when it is okay to commit and how often developers should be getting from the trunk. Frequent commits shouldn't be a problem given that you are trying to isolate breaking changes to feature branches.
2. Institute a continuous integration process. This further ensures that you don't end up with huge integration headaches at the end of an iteration, provides notification if something has broken, and let's you automate more of your QA both through automated unit/acceptance tests and potentially through static analysis/code inspection tools. I have found CI provides great "bang for the buck" as an investment in the configuration management process. Note, there is a tension between CI and using feature branches heavily because the branches essentially let you keep the trunk clean, pass your tests in CI, but still create conflicts/issues in the branches. Frequent merges back into the trunk can help with this as can running CI in the branch and pulling from the trunk frequently, but a proliferation of branches will start to defeat the CI process either by complicating its administration, or simply ignoring it in the branches.

Answer 4

From what you state:
Your code resides in trunk
For each major feature / enhancement - you cut a branch off trunk - develop and then provide to QA to test
All major and important bugs get fixed in this 'QA branch'
Post QA you 'trunk' the code from this branch back to trunk

This sounds pretty ok strategy to me
we have been regularly branching , merging and trunking into SVN using eclipse svn plugin or tortoise
Looks good to me

Answer 5

It sounds fine, I'd worry that the QA branch is relatively short-lived, and I would do all fixes related to that release on that branch so they get merged to trunk on 1 go rather than fixing them on trunk as they are found.

If you fix the trivial bugs on the QA branch then the testers can see and mark them off quickly. I assume they get daily/weekly builds off the QA branch, so trivial bugs shouldn't be time consuming at all if done on QA. (I speak from experience where the tiniest of tiny bugs can have a knock-on effect that causes major grief elsewhere)

One potential improvement I could mention is to do feature development on a branch - ie move the work you usually do on trunk to a dedicated branch instead. Then trunk will only have merges committed to it, which can help in tracking changes that are complete.

Answer 6

You mention several things which are likely to increase awkwardness and reduce the chances of success for your project:

The project will be 1 year and production deployment will only occur towards the end of the project.

I really, really recommend that you deploy to a production-like environment as often as possible, ideally every day. Leaving so-called 'productionization' to the end of the project usually results in unforeseen problems. The anti-patterns here are 'late integration', and 'late production deployment'.

1 month per iteration

A month is a very long iteration heartbeat, and few developers will be able to remember clearly what they were working on at the start of the iteration. I'd recommend going for 2-week iterations, delivering in smaller batches. Anti-patterns: 'large batch sizes', 'long cycle time'.

Feature Branch

You should probably avoid feature branches, unless you also use integration branches. Ideally, use feature toggles and branch-by-abstraction instead. Feature branching tends to lead to unexpected late integration problems. Anti-pattern: 'late integration'.

We're using SVN.

Merging is pretty painful in Subversion, even if you use the merge-tracking features of v1.5 and later. I recommend you switch to Git - you'll never look back. Merging with Git is painless compared to with Svn. I used Subversion for many years, and was initially skeptical of Git, but I am now 'sold'. The only things I'd use Svn for over Git are for storing binary files (if really necessary!) and for things like RANCID which are in complete control of the repo. For source code control, Git beats Subversion every time.

I recently wrote about work I have done on releasing from trunk/mainline/master and avoiding feature branches, which might give you some further 'food for thought': Leaving the Platform – Branching and Releasing for Independent Subsystems

Also, read some posts on Martin Fowler's site, such as ContinuousIntegration, FeatureBranch, and BranchByAbstraction.

Finally, buy a copy of Continuous Delivery by Jez Humble and David Farley and work through the recommendations - it's a hugely valuable book, and every developer should own a copy. I have found it useful to print out the Contents pages and put them on the wall to track progress :) Even if you don't intend to delivery continuously, so many of the practices in this book are really healthy and vital for successful software delivery today.

Hope this helps.

M