Best branching strategy when doing continuous integration?

Question

What is the best branching strategy to use when you want to do continuous integration?

1. Release Branching: develop on trunk, keep a branch for each rel

Answer 1

I personally find it much cleaner to have a stable trunk and do feature branching. That way, testers and the like get to stay on a single "version" and update from trunk to test any feature that is code complete.

Also if multiple developers are working on different features, they can all have their own separate branches, then merge to trunk when they're done and send a feature to be tested without the tester having to switch to multiple branches to test different features.

As an added bonus, there is some level of integration testing that comes automatically.

Answer 2

I think the tools you use are a big factor here.

• If you are using subversion, sticking with option 1 and release from branches.
• If you are using GIT, option 2 will work well for you.

Answer 3

Continuous integration should not be any kind of a factor in determining your branching strategy. Your branching approach should be selected based on your team, the system under development and the tools available to you.

Having said that ...

• there's no reason why CI couldn't be used in both of the approaches you describe
• those approaches work quite well in combination
• neither of the two work "better" than the other
• CI makes total sense with an unstable trunk

All of this was answered in the fourth question on the page that you took the diagrams from: http://blogs.collab.net/subversion/2007/11/branching-strat/

Answer 4

When we started our team we inherited a release-based strategy from the vendor that originally developed the system we were about to get in charge of. It worked up until the time when our customers requested that several developed features should not be included in a release (f.y.i. ~250k lines of code, ~2500 files, Scrum with XP SDLC).

Then we started looking at feature-based branches. This also worked for a while - like 2 months until the point we realized that our regression testing process would take over 2 weeks which combined with the uncertainty of what would be released created a huge inconvenience.

The final "nail in the coffin" of pure SC strategies came when we decided that we should have 1. stable trunk and 2. Production should contain ST, UAT, and Regression tested BINARIES (not just source - think CC.)

This lead us to devise a strategy that is a hybrid between feature and release-based SC strategies.

So we have a trunk. Every sprint we branch out the sprint branch (for the non-agile folks - a sprint is just a time-boxed development effort with variable output based on complexity.) From the sprint branch we create the feature branches and parallel development starts in them. Once features are complete and system tested, and we receive intent to deploy them, they are merged to the sprint branch - some may float across several sprints, usually the more complex ones. Once the sprint is near its end and the features are complete ... we "rename" the sprint branch to "regression" (this allows CruiseControl to pick it up without any reconfiguration) and then regression/integration testing begins on the cc-built EAR. When that is all done, it goes in production.

In short, feature-based branches are used to develop, system test and UAT functionality. The sprint branch (really the release branch) is used to selectively merge features on-demand and integration-test.

Now here is a question to the community - we are obviously having trouble performing continuous integration because of the fact that development happens on many branches and the reconfiguration overhead of CruiseControl. Can someone suggest and advice?

Answer 5

I've recently come to like this model when using git. Although your question is tagged "svn", you might still be able to make some use of it.

Continuous Integration can to some extent happen in the "develop" branch (or whatever you call it) in this model, though having long running feature branches for future releases wouldn't make it so rigid as to consider every change happening to code somewhere. The question remains, whether you'd really want that. Martin Fowler does.

Answer 6

Release branches are very useful, and even absolutely required, if you need to maintain several versions of your app.

Feature branches also are very convenient, notably if one developer needs to work on a huge change, while others still release new versions.

So to me using both mechanisms is a very good strategy.

Interesting link from the Book of SVN.