Introduction
You might have heard of trunk-based development (a.k.a. TBD) and perhaps even heard that tech leaders - including Google, Facebook, Netflix, and Microsoft - have adopted this approach. You might be wondering what TBD is, why it might be worth adopting, and whether it is a good fit for your organization.
At RingStone, we work with a broad cross-section of development teams in our technical diligence work, digging into what’s working and what isn’t, and we can attest that trunk-based development – on the right teams – can be a very productive option.
In this blog post, we’ll explore trunk-based development, the benefits it offers, and the prerequisites necessary for successful implementation.
What is Trunk-Based Development?
Distilled down to its essence, trunk-based development means that developers merge their changes to the main code line at least once a day, and the main branch is always in a releasable state
At its core, trunk-based development means that developers merge their changes to the main code line at least once a day, and the main branch is always in a releasable state. There is, of course, some variation in how teams handle this approach. Some teams have a system in which commits are always made to the local version of the main branch but must pass tests before being pushed. Others use feature branches but only allow these to exist for a day or have some mechanism to ensure they are synchronized with the main branch at least daily.
In the most extreme example I’ve heard of, automated scripts were set up to delete any work done by developers if it wasn’t merged to the main branch by the end of the day! While this level of enforcement is rare, it underscores the core principle. If you’ve only worked on teams that used long-lived branches, this could sound bizarre. Nonetheless, it is achievable - and many high-performing teams strongly advocate for the approach. Let’s take a closer look.
To begin, there are some things most would agree are desirable in software development:
Being able to verify quickly and automatically that the code is functioning as intended
Having a shared sense of code ownership, with minimal key person risk
Decoupling the development process from the marketing process
Releasing frequently and rapidly
Responding quickly to emerging customer needs
Spending as little time as possible on unproductive work, such as merging code and manually resolving conflicts
Advocates of trunk-based development argue that it supports all of these goals.
Costs and Prerequisites
So, can we just jump in and start doing it? Not quite. For it to work effectively, there are several important prerequisites that must be in place. However, advocates note that these are foundational practices development teams should implement regardless.
In effect, adopting trunk-based development forces us to get our act together and improve our processes in a few key ways – which is part of its appeal
In effect, adopting trunk-based development serves as a catalyst for improving processes - which is part of its appeal.
Automated Testing
First, we need to have great automated testing in place. If we can’t verify software is release-ready automatically – as in, entirely from tests run in the build pipeline – we’re not ready for TBD. In a TBD workflow, we use a Continuous Integration (CI) pipeline to run all the tests prior to merging to the mainline, and we need to be 100% confident that, if those pass, our work is not going to have unintended consequences on other people’s works or result in broken releases. This requires testing to be as important a part of a developer’s work as implementation, whether we’re doing test-first development or writing tests concurrently. Writing implementations and coming back to the tests the next day won’t work in a TBD workflow.
This prioritization of testing is not optional. It must have complete support from management. If you’re at an organization where management might decide that a feature needs to go out the door in such a rush that testing can be deferred to later, you aren’t going to be able to do TBD, no matter how competent the developers are. Trunk-based development optimizes for the long run.
Shared Ownership
Successful adoption of trunk-based development requires a team in which each member understands - and shares responsibility for - a substantial portion of the codebase. With TBD, we review each other’s code and merge multiple times a day. This model is not sustainable if, for example, only two individuals are capable of reviewing front-end code, and one of them is unavailable on certain days.
A well-distributed team with overlapping areas of expertise is essential. TBD is not well-suited to environments where a single “rock star” developer works in isolation for extended periods without collaboration. Trunk-based development is designed to optimize for the team, not the individual.
The astute reader may have noted that these two prerequisites were already on our list of benefits. In many ways, preparing to adopt TBD acts as a forcing function for improving foundational development practices.
Architecture
In order for TBD to work well, we may need to change how we build software. We need to architect the system such that, whenever possible, a new version of a component replaces its predecessor, not by the alteration of code, but rather through the addition of code. This approach ensures that the older version continues to run without issue right up until we flip the switch – and that we can always flip the switch back to revert to a previous version. This approach also mitigates caused by multiple developers working on the same parts of a file and creating conflicts. There is no risk that an incomplete implementation of a new component will compromise the older version since both versions remain in the codebase and are executable.
The most common approach to this is to use feature flags - configuration switches that control which version of a component is executed in production. These flags could be stored in a database, in configuration files, or even in environment variables. The practice of altering systems by only adding new code has been used for decades and is explored in depth in classics such as the hugely influential Design Patterns: Elements of Reusable Object-Oriented Software (1994), often referred to as the “Gang of Four” book. It covers using component registries, adapters, and dependency injection to build systems out of additive components rather than increasing the complexity and branching within existing code.
At this stage, it may appear that trunk-based development introduces considerable architectural overhead - and to some degree, that is accurate. The total volume of code in the system often increases, whether due to the use of feature flags or the implementation of configuration systems that inject adapters. However, advocates of TBD argue that these architectural costs are outweighed by the resulting benefits. The main code line remains consistently deployable, and teams gain the ability to switch between new and legacy components seamlessly. This brings us back to the core set of development goals outlined earlier.
Benefits
First, trunk-based development allows teams to fully decouple the code release schedule from the feature release schedule. If the main branch always works and is always releasable, there’s no reason not to be deploying code all the time. We don’t need to synchronize the implementation of features with the marketing of features, and we don’t need to use a preset sprint cadence for releasing to production. One of the best companies I’ve conducted diligence on was a small team practicing TBD and releasing up to nine times a day! This allowed them to respond faster to markets, customers, and changes in dependencies and third-party systems. Few things build customer trust more effectively than delivering an improvement or fix on the same day an issue is reported.
Second, trunk-based development enables teams to respond more quickly to critical issues by allowing easy reversion to previous versions of components. Regardless of how well we test code, sometimes we release “bugs” that are really a result of misunderstanding what the customer wants. The code is fine – it passes all the tests – but we built the wrong thing or designed it incorrectly. Without feature toggles, reverting requires us to roll back to previous generations of the entire codebase, potentially adding all kinds of conflict-management work if the codebase has moved on in other ways. In a feature-toggled scenario, we can flip the switch back and forth as much as we want. If the toggle system is database-driven, it may even be possible to manage rollbacks on a per-customer basis.
By keeping branch lifecycles to a day, we ensure that merging is always a simple affair
Third, trunk-based development reduces the effort associated with resolving merge conflicts - a common and often time-consuming challenge in software development. It’s a truism that the longer-lived a branch is, the harder the merging process becomes. By keeping branch lifecycles to a day, maybe two at the most, we ensure that merging is always a simple affair. This also helps ensure that no one is inadvertently working in a silo for a long time, potentially building something we later need to throw away. Proponents of TBD argue that the time lost managing merge conflicts in long-lived branch strategies often exceeds the effort required to architect systems in an additive, TBD-compatible manner - and that this architectural investment yields additional long-term benefits.
Trunk-based development optimizes for the team rather than for the individual developer
Fourth, proponents contend that trunk-based development optimizes for the team rather than the individual developer. With everyone working on nearly the same version and an always runnable mainline, we foster a much greater sense of team ownership of the code. Each developer has visibility into others’ contributions as recently as the previous day, and everyone is working with code that is, at most, one day out of sync.
This high degree of alignment simplifies code reviews and makes it more feasible to expose a broader segment of the team to a wider portion of the codebase. This reduces key person risks and creates a culture that values and prioritizes team responsibility and team interactions over individual, rock-star contributions.
But Does It Scale?
You may find yourself intrigued, but wondering whether this approach scales. In fact, scaling is one of the major selling points of trunk-based development. As teams and code bases grow, long-lived branches become increasingly problematic. The odds of conflicts from one developer altering code on their own for a week get higher and higher.
On the other hand, the additive nature of trunk-based development means that, while the code grows, the odds of conflicts stay fairly constant. Provided a good component registration and toggling system in place, the number of developers - whether ten or one hundred - has minimal impact on workflow efficiency. This is one of the major reasons software leaders like Google and Microsoft have embraced this approach.
Trunk-based development supports large-scale repositories and teams. It also serves as a powerful cultural enabler, aligning teams around consistent testing standards and review practices.
Conclusion
If the advantages of TBD would make a positive difference to your organization and you can meet the requirements, TBD may be a great fit
If the advantages of trunk-based development align with your organization’s needs - and you are able to meet its requirements - it may prove to be a highly effective model.
Now, it must be said that one of the things we see when we conduct technical diligence at RingStone is that most teams lack the mature test coverage necessary to adopt TBD effectively.
Additionally, there are certain domains in which trunk-based development is not feasible. For example, teams operating under strict code safety audit requirements may be unable to include unfinished or deactivated code paths in their mainline. As is often the case in software engineering, there is no silver bullet.
Even if trunk-based development is not the right fit for your team, understanding its principles - as practiced by leading technology organizations - can inspire valuable conversations about improving development workflows, quality assurance practices, and architectural decisions.
About The Author
Iain C.T. Duncan has spent the last 20 years working in the software industry as a CTO, developer, software architect, and consultant, building B2B and internal web applications at startups, agencies, and early-stage companies in Canada and the U.S.
As a practitioner at RingStone, he works with private equity firms globally in an advisory capacity, conducting technical diligence on early and mid-stage companies and preparing companies for the diligence process. He has worked in the diligence sector for six years and has been involved in hundreds of diligence efforts as a practitioner, reviewer, and trainer. Before the diligence sector, he worked on software in e-commerce, association management, non-profit fundraising, genomics, and online education, among others.
An active open-source developer and researcher, Iain is currently completing an interdisciplinary PhD in Computer Science and Music at the University of Victoria, working on applications of Scheme Lisp to algorithmic music and music pedagogy. He is the author of the Scheme for Max open-source programming extension to the Max/MSP audio programming platform and is the founder and developer of the online music education platform SeriousMusicTraining.com.