Dave Farley and Jez Humble have been championing the importance of trunk based development since long before their pivotal book on Continuous Delivery was published in 2011. Farley recently wrote about trunk based development and the backlash of objections which he has encountered following his talk on Optimising Continuous Delivery at the PIPELINE conference in March. In support of this, Humble shared his own perspectives in a lengthy Twitter thread which inspected the cultural aspects of trunk based development to understand its relation to the programmer mindset.
Farley described trunk based development as the practice which he "gets the most push back on." Trunk based development encourages teams to work in a fashion where they push incremental changes, at least daily, to a shared and always releasable mainline trunk. In contrast to the practice of using longer-lived feature branches, this facilitates early learning and shared feedback for everyone with a stake in the product being built. "Most teams don't merge their branch until the 'feature' that they are working on is complete," wrote Farley who describes trunk based development as a cornerstone of continuous integration (CI) and continuous delivery (CD). He wrote that such feedback isolation is contrary to the practice of CI:
...if CI is about exposing our changes as frequently as possible, so that we can get great feedback on our ideas, branching, any form of branching, is about isolating change. A branch is, by-design, intended to hide change in one part of the code from other developers. It is antithetical to CI, the clue is in the name "CONTINUOUS INTEGRATION".
Farley described feature branching as often providing a misleading sense of stability, within a dynamically changing code base:
Feature Branching is very nice from the perspective of an individual developer, but sub-optimal from the perspective of a team. We would all like to be able to ignore what everyone else is doing and get on with our work. Unfortunately code isn't like that. Even in very well factored code-bases with beautiful separation-of-concerns and wonderfully loosely-coupled components, some changes affect other parts of the system.
Picking up on this Humble wrote that trunk based development is about "putting the needs of the team above the needs of the individual." He pointed out that effective trunk based development encourages communication and working with small batches:
We're using version control to communicate what we're doing to the rest of the team. To do it regularly enough, we have to work in very small batches. This is antithetical to the way lots of developers like to work: sitting off on their own going down a coding rabbit hole for days before re-emerging.
Humble wrote that CI and its prerequisite of trunk based development are "social and team" activities, creating a "challenge to the mythos of the developer-as-hero":
Thus my hypothesis about why feature branching vs CI / trunk based development is such a hot button issue: we are striking at one of the central beliefs about what it means to be a "good" programmer. There's also the fact that people aren't trained to work in small batches and find it uncomfortable.
Considering the effort which teams can put into testing and seeking feedback loops against branches mismatched with what will be released, Farley wrote:
The definitive point is the testing that happens at the point of merge to trunk. It is only at this point that you can honestly say, "Yes, my change works with everyone else's." Before that, you are hoping that someone else hasn't done something horrid on another branch that breaks your stuff when you merge.
Farley wrote that trunk based development is a core component of being successful with CI and CD:
CI is not a naive approach; it is well-thought out and very widely practised in some of the most successful companies in the world. Trunk-based development is a core practice to CI and CD, it really is very difficult to achieve all of the benefits of CI or CD in the absence of Trunk-based development.
Farley has refuted objections to trunk based development, citing the State of DevOps Report and his own personal experience of having succeeded with the practice for several decades, across varied team sizes, programming languages and scales.
Humble recently co-authored the book Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, which took on the challenge of empiricising, collating and statistically quantifying the impact of companies practising continuous delivery. In his twitter thread about Farley's post, Humble tweeted:
...we did some research on working off trunk in the State of DevOps Report, which is also in our new book, Accelerate. The results are clear. Teams which work off trunk or branches which last less than a day have significantly higher performance.
In his forward for Accelerate, Martin Fowler summarised the benefits of working with these practices:
They describe how effective IT delivery organizations take about an hour to get code from committed-to-mainline to running-in-production, a journey lesser organizations take months to do. They thus update their software many times a day, instead of once every few months, increasing their ability to use software to explore the market, respond to events, and release features faster than their competition. This huge increase in responsiveness does not come at a cost in stability, since these organizations find their updates cause failures at a fraction of the rate of their less-performing peers, and are usually fixed within the hour."