Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News More Feature Branching Means Less Continuous Integration

More Feature Branching Means Less Continuous Integration

This item in japanese

Many teams now implicitly discard continuous integration due to ever-easier feature branching and an under-appreciation of trunk based development, says Steve Smith. At the Agile Tour London 2015 he will talk about the death of continuous integration.

InfoQ interviewed Steve Smith about different branching approaches and how they can be combined with continuous integration, and how using build feature branching can hamper continuous integration and continuous delivery.

InfoQ: Can you briefly describe some of the different branching approaches that are being used?

Steve Smith: Sure. Over the past year I’ve written a series of articles on some very different version control strategies, all of which I’ve used at some point in my career. I wanted to assess their historical context, establish a taxonomy for different styles of Feature Branching, assess their compatibility with Continuous Integration - and answer a question from a colleague: "why would I do Trunk Based Development when I’m doing Build Feature Branching so well?"

In the 1990s old school, long-lived Release Feature Branching was popular with tools such as ClearCase, Perforce, and MKS. Developers worked on shared feature branches for weeks, months, or maybe even years with entire epics developed and tested on branches before being released into production. Afterwards there would be a painful, time-consuming merge into Trunk plus regression test. I did Release Feature Branching for 2 years at a company using MKS, and I do not recommend it.

From the early 2000s onwards Trunk Based Development has been used with tools such as Subversion and Perforce. Developers work on Trunk with multiple commits a day in small, incremental steps. Testing happens on Trunk, and production releases either happen from Trunk or short-lived release branches. Parallel feature development is accomplished using techniques such as Feature Toggles and Branch By Abstraction backed by user preferences, runtime configuration, etc. I did Trunk Based Development for 7 years at 3 companies using Subversion, Mercurial, and Git and I highly recommend it to everyone - colleagues, family, friends, strangers in the street.

In the mid-2000s Distributed Version Control Systems (DVCS) became mainstream, and while Trunk Based Development is equally applicable to VCS and DVCS the lower cost of branch creation in DVCS led to more lightweight Feature Branching strategies emerging. One variant called Integration Feature Branching became used with tools like Git and Mercurial. Developers work on individual feature branches for ideally a day before merging to a long-lived Integration branch for testing, after which point the Integration branch would be merged into Trunk or in the case of Git Flow feature release branches prior to Trunk. I did Integration Feature Branching for 6 months using Git Flow, and I do not recommend it at all.

Finally, since the late 2000s Build Feature Branching has burst onto the scene thanks to Git, Mercurial, and particularly GitHub Flow. Developers work on individual feature branches for ideally a day, with features then merged into Trunk for testing and production release. I’ve been doing Build Feature Branching for 1 year at a client using GitHub Flow, and I would recommend it - albeit it very cautiously.

InfoQ: Can you elaborate how these different branching approaches can be combined with continuous integration?

Steve Smith: Firstly, Continuous Integration is not a tool - it is a practice where every member of a team commits to Trunk at least once a day, which might be verified by a build server such as Jenkins or TeamCity. Therefore we can assess a version control strategy based on its ability to facilitate daily commits to Trunk (call Master if you want, it doesn’t matter). Firstly, Release Feature Branching and Integration Feature Branching are both clearly incompatible with Continuous Integration as the former involves months on a shared branch and the latter involves a plethora of branches prior to Trunk.

Trunk Based Development is synonymous with Continuous Integration, and for good reason - when every team member is committing to Trunk multiple times a day Continuous Integration is achieved. There are also other benefits to explore, such as team members being nudged towards decomposing the codebase into a smaller, modular Evolutionary Architecture and Feature Toggles being used for Canary Releases and Dark Launching.

Build Feature Branching is really interesting. On the face of it individual feature branches being reviewed and merged into Trunk seems compatible with Continuous Integration, but after much thought I’ve concluded that Build Feature Branching is probably incompatible with Continuous Integration - feature branches end up being longer than a day due to developers picking up more changes, reviews take longer than a day due to developer workload, and builds become slower and more broken as a result of developers working asynchronously from the Trunk merge and build.

InfoQ: At the Agile Tour London you will talk about the "Death of Continuous Integration". Why death?

Steve Smith: During the #IsTDDDead debate in 2014, I looked around at my team and saw everyone practising Test Driven Development using GitHub Flow and I thought "Test Driven Development is alive and well, but Continuous Integration is in real trouble".

Build Feature Branching is phenomenally popular now, and I would guess that is due to a) Git and GitHub being such good tools and b) companies increasingly turning to the open-source community for ideas and inspiration. In the Stack Overflow 2015 survey 11,519 of 16,694 (69%) of developers reported Git as their source control tool, and GitHub Press in July 2015 reported 10 million users and 26 million repositories. Now, Git is a very nice tool, and so is GitHub. But Continuous Integration is phenomenally important - it is the foundation of Continuous Delivery - and I believe a lot of teams will struggle to implement a long term, sustainable Continuous Delivery programme if they blindly adopt Build Feature Branching.

InfoQ: Can you share some resources that InfoQ readers can use to learn more about branching and continuous integration?

Steve Smith: For information on Continuous Integration, I’d recommend the original article on continuous integration by Martin Fowler and The Art Of Agile Development by James Shore and Shane Warden. For information on branching models and source control, Paul Hammant’s blog is a great source of information.

InfoQ will cover the Agile Tour London 2015 with news, Q&As and articles:

The 3rd edition of the Agile Tour London will happen Friday 23rd October 2015. It’s an event open to everyone interested in Agility: From Agile Practitioners to Agile Newbies.

Rate this Article