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 release.
2. Feature Branching: develop each feature in a separate branch, only merge once stable.

Does it make sense to use both of these strategies together? As in, you branch for each release but you also branch for large features? Does one of these strategies mesh better with continuous integration? Would using continuous integration even make sense when using an unstable trunk?

Solution 1

I find the topic really interesting since I heavily rely on branches on my daily job.

• I remember Mark Shuttleworth proposing a model about keeping the main branch pristine while going beyond conventional CI. I posted about it here.
• Since I'm familiar with Cruise Control, I also blogged about task branches and CI here. It's an step by step tutorial explaning how to do it with Plastic SCM.
• Finally, I found some of the topics about CI (and potentially talking about branching) at Duvall's book on CI very interesting too.

Hope you find the links interesting.

Solution 2

The answer depends on the size of your team and quality of your source control and the ability to merge correctly complex change sets. For example in full branch source control like CVS or SVN merging can be difficult and you might be better off with the first model, while if using more complex system like IBM ClearCase and with a larger size of team you could be better of with the second model or a combination of the two.

I personally would separate the feature branch model, where each major feature is developed on a separate branch, with task sub-branches for each change done by individual developer. As features stabilize they get merged to trunk, which you keep reasonably stable and passing all regression tests at all times. As you near the end of your release cycle and all feature branches merge, you stabilize and branch of a release system branch on which you only do stability bug fixes and necessary backports, while the trunk is used for development of the next release and you again branch off for new feature branches. And so on.

This way trunk contains always the latest code, but you manage to keep it reasonably stable, creating stable labels (tags) on major changes and feature merges, the feature branches are fast paced development with continuous integration and individual task sub-branches can be often refreshed from the feature branch to keep everyone working on the same feature in sync, while simultaneously not affecting other teams working on different features.

At the same time you have through the history a set of release branches, where you can provide backports, support and bugfixes for your customers who for whatever reason stay on previous versions of your product or even just latest released version. As with the trunk, you do not setup continuous integration on the release branches, they are carefully integrated upon passing all regression tests and other release quality control.

If for some reason two features are co-dependent and need changes done by each other, you can consider to either develop both on the same feature branch or to require the features to regularly merge stable parts of the code to trunk and then refresh changes from trunk to exchange code between trunk branches. Or if you need to isolate those two features from others, you can create a common branch off which you branch those feature branches and which you can use to exchange code between the features.

The above model does not make much sense with teams under 50 developers and source control system without sparse branches and proper merging capability like CVS or SVN, which would just make this whole model a nightmare to setup, manage and integrate.

Solution 3

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.

Solution 4

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.

Solution 5

I think either strategy can be used with continuous development provided you remember one of the key principles that each developer commits to trunk/mainline every day.

http://martinfowler.com/articles/continuousIntegration.html#EveryoneCommitsToTheMainlineEveryDay

EDIT

I've been doing some reading of this book on CI and the authors make suggest that branching by release is their preferred branching strategy. I have to agree. Branching by feature makes no sense to me when using CI.

I'll try and explain why I'm thinking this way. Say three developers each take a branch to work on a feature. Each feature will take several days or weeks to finish. To ensure the team is continuously integrating they must commit to the main branch at least once a day. As soon as they start doing this they lose the benefit of creating a feature branch. Their changes are no longer separate from all the other developer's changes. That being the case, why bother to create feature branches in the first place?

Using branching by release requires much less merging between branches (always a good thing), ensures that all changes get integrated ASAP and (if done correctly) ensures your code base in always ready to release. The down side to branching by release is that you have to be considerably more careful with changes. E.g. Large refactoring must be done incrementally and if you've already integrated a new feature which you don't want in the next release then it must be hidden using some kind of feature toggling mechanism.

ANOTHER EDIT

There is more than one opinion on this subject. Here is a blog post which is pro feature branching with CI

http://jamesmckay.net/2011/07/why-does-martin-fowler-not-understand-feature-branches/

View more solutions

Comments

[Keith Pinson]

Side note: some would argue that even as new features are put it in, everything should always be stable. On the other hand, that might be somewhat idealistic.

[KingNestor]

Also, do you still branch and tag for each major release? Or just tag?

[Adnan]

It works well with CI as long as feature branches are merged into trunk with some discipline so as not to have broken builds. I do branch and tag for each production release which will be used for bug-fixing only. That can be merged into the stable trunk immediately.

[eglasius]

@king I would say that probably depends on what you call major release, but in either case you can tag, and branch later when you need it (based on the tag :))

[KingNestor]

It has some more as well. But I feel like Feature Branching and Release Branching are the 2 most common.

[Jiri Klouda]

Of course, there are benefits for teams of any size. The question is at what team size the benefits outweigh the costs associated with a heavy process.

[pablo]

We added support to Bamboo to do branch per task codicesoftware.blogspot.com/2012/02/…, and it seems their newest version will do it natively with several version controls, including dvcs.

[RaoulRubin]

I don't necessarily agree with the conclusions, but thanks for the discussion of your process. There is no one-size-fits-all solution.

[Jason S]

O'Reilly chapter no longer accessible

[hdost]

Feature branching can be easily achieved with any SCM

[Jirong Hu]

interesting, can't find this post anymore.

[Yani]

This is similar to the GitFlow, and/or GitHubFlow, model. I don't think these models facilitate Continuous Integration (CI). In my opinion, Trunk Based Development is a significant improvement on these models.

[Jiri Klouda]

You can see that this comment actually pre-dates the original release of git flow. Not quite sure what you mean by "better". I've supported teams of 1, 5, 25, 150, 1,000 and 20,000 developers working on projects that were integrated to some extent. Requirements vary and "better" is very much relative term. Do you need to backport code ever? Security fixes? If not, then your life is simple. SaaS is a direct result of restrictions imposed by trunk based development. Feature flags are just as complex as feature branches. Except you only find out from customers when a permutation of them breaks.

[Jiri Klouda]

Dave Farley and Jez Humble are simply wrong in their stance on branching. The reason for it is that it encodes important assumption "you will never have to manipulate code at feature level and if, then it is ok for it to be expensive operation" and they base their assessment on another assumption "merging is too expensive with automated merges being nearly impossible at scale". If those two assumptions are not true, if you live in world where merging is cheap, but need to manipulate code at feature level for back ports and security fixes, then their statements break down. It's a rare case tho.

[Jiri Klouda]

Some companies also need to move features forward to future releases, after those features hit roadblocks in implementation and are holding up a release. Sometimes there is an option to leave the code in, like in SaaS products, but if the code is released to customers, it might not be an option as it can be analyzed by competitors. So much code these days is not compiled and even if it is, defines/feature flags in code are on the same complexity level as branches.