Choose Continuous Integration over Branching for Faster Feedback
Scrum and other agile software development methods provide a process framework for your project, but success depends on using the correct technical processes to deliver reliably.
At the core of all agile methods is continuous feedback, and your source code management policies determine how easy it is to get this feedback in a timely manner. In particular, choosing policies that allow for frequent integration and testing is key.
Continuous integration is the best way to get feedback often on the state of your project. While “continuous” is an ideal, a practical definition of continuous integration is that each person commits their changes to a shared source code repository at least once a day. More frequently is better, and running automated builds and tests after each integration is what gives you feedback that improves reliability and predictability.
Trunk-based development, also known as mainline development, where all work is integrated into a single code line, can be the best approach to ensuring continuous integration. Approaches that use task and feature branches, while useful in some cases, can be a distraction. Trunk-based development forces you to have an always up-to-date view of the system.
The costs of delaying integration can be high, so continuous delivery consultant and agile technical coach Thierry de Pauw says it’s best to avoid feature branching. While branching always had a cost, distributed version control systems such as Git hide many of the mechanical complexities, but the integration costs remain. Rather than decreasing risk by limiting the change a developer sees while working, it increases risk by delaying uncertainty until later in the process. The sooner a team sees a problem, the sooner it can inspect and adapt while still delivering value.
A better approach is to embrace the core idea of continuous integration: frequent integration of all the work by everyone on the team. De Pauw’s presentation also explains ways to achieve some of the perceived benefits of source code branching while avoiding the risks. Feature toggles and branching by abstraction provide ways to allow for alternate functionality while maintaining the ability to build and test a single code base on every change.
However, branching is not intrinsically bad, provided you understand the risks and know when and how to do it. Story branches might be useful, for example, as long as the work can be completed in a day. Likewise, pull requests and code reviews are useful, as long as you meet the criteria of daily integration.
Still, although tools have made branching easier, branches delay feedback, which is essential to effective agile software development. Whether branching will help or hinder your agile team depends on the structures you have in place for support. Frequent integration of all work into a mainline is an effective approach. Treat longer-lived branches as an exception at your own peril.
