Trunk-Based Development Enablers
It's more than just the code line
Development practices such as test-driven development, Continuous Integration, and a guide to agile code lines — Software Configuration Management Patterns — have been around for a while, yet teams still struggle to find a low-overhead approach to integrating code quickly and safely. Given all the information available, why don’t people simply fix the problem? The reasons can vary by team, but three:
Change is hard. If what you are doing works well enough or seems like an industry standard, change can feel uncomfortable or risky, despite the potential upsides.
People tend to focus on process rather than underlying mechanisms. It’s normal to want to look for point solutions, rather than doing the work to address root causes.
Even when we do look for deeper causes, people tend to look at the metrics that are proximate to the perceived issue. Success often depends on other, seemingly unrelated changes.
Much like “adopting agile” by holding “the right” meetings won’t fix a flawed software development process without changing how you plan work and develop code, switching to a new code line model without other process changes won’t yield faster value delivery. In fact, the changes that will make your code lines more agile will make your process more agile too.
What to Measure
When teams talk about the problem of code not integrating quickly enough, they sometimes focus on things like PR Cycle Time. While this measure can indicate bottlenecks in the delivery process, what you really care about is time to integration: How long between the time a task is started and it gets merged into the Main Line.
In many cases, the delays in the PR process indicate issues in the upstream parts of the delivery pipeline. While it’s tempting to say “let’s get rid of Pull Requests and branching and follow Trunk Based Development so that changes get to the Main Line more quickly,” it won’t work unless you consider what may be causing the underlying issues, and in fact, a Pull Request could even facilitate you moving to faster integration.
While Trunk-Based Development avoids any long-lived branches other than a shared Main Line integrating directly from your workspace into the Main Line isn’t the only approach; Trunk-Based Development doesn’t prohibit branching. And avoiding branching doesn’t address all the issues that are blamed on branches.
What to Change
It’s true that certain branching models can expedite or slow down integration. A Trunk Based Development approach has the potential to be faster than, say, Git Flow, but asserting a branching strategy doesn’t guarantee anything:
You may still have to wait for reviews/feedback
Changes can sit in a developer workspace for a long time (and thus diverge from the Main Line ) either because the work item is complex or the developer doesn’t work in a way that allows for frequent integration of work in progress.
Merges can break the Main Line if you don’t have the right mechanisms in place.
Automated steps that merge code between branches can make branching transparent.
To integrate code quickly, you need to consider how you:
Plan: Small Development Tasks are quicker to integrate.
Work together: Pairing, or having a Feature Partner who can give feedback quickly, will reduce waits for reviews.
Test: Unit Tests, and Automated Checks that you can run in a workspace or in your CI Pipeline will help human reviewers focus on the right things.
Set up workspaces for developers: A consistent Developer Workspace with a uniform build will help reduce errors that are first seen in CI.
Design: if your architecture supports committing work in process, either through Feature Flags or staged delivery, you can avoid larger units of work.
Improve your process: you won’t get it right the first time, and having a culture that supports taking time for feedback and retrospectives can help you continue to reduce bottlenecks and friction.
While you can do all of these things in the context of direct integration to the Main Line, a Pull Request tool can be a good way to automate the more mundane aspects of code reviews, such as style, compliance, and test execution, through automated checks. This allowshumans to give you feedback on understandability and other things that automation can’t verify.
All of these things also help you build an agile code base.
Focusing on the question: “Are we integrating code quickly enough? “ helps you to understand that the things that make PRs slow are the things around the process, not the process itself.
Trunk-based development takes some work, and some of that work might involve changes outside the coding process, including planning, testing, and build automation. And you may be able to leverage a streamlined version of your pull request process — with short lived branches —to help.