Having a pipeline isn’t enough.
If I went around the office and surveyed the development teams, I don’t think many would say they aren’t using Continuous Integration (CI). However, if I asked how many were employing Trunk-Based Development (TBD), the number would be far smaller. Somewhere along the way, something has been lost in translation.
Continuing our hypothetical conversation, the next question would be for teams to define what their CI processes actually are. I’m sure they’d point to a pipeline, hopefully show some tests, and explain that it runs automatically when they try to merge a branch / after a merge has completed. The “continuous” element is there—but the “integration” part is slightly off.
Integrating into what is the key question for this article. As the introduction hints, it is rarely a main (or trunk) branch. Instead, teams often opt for release or feature branches that track a specific piece of work or project.
At this point it’s probably worth recalling why we signed up to CI in the first place:
- Catch bugs earlier
- Deploy faster
- Reduce merge conflicts and integration headaches
Does feature branching achieve these goals? Partially—but there’s still a long way to go.
When you eventually incorporate your feature branch back into main, bugs will still appear for code that is now stale. You won’t be deploying as frequently as you could, because you won’t be able to move into Continuous Delivery or Continuous Deployment. And while you may reduce the number of merge conflicts you encounter day-to-day, they will still be waiting for you when you merge back into main. By that point the code is no longer fresh in your head, making those conflicts even nastier to resolve.
Adopting true CI—via trunk-based development—can feel intimidating at first. But it creates a virtuous cycle where small changes encourage continuous improvement. Why is this?
Batch size is smaller
With a faster integration cycle, developers are expected to push code into main daily rather than weekly or monthly. This keeps reviews smaller and easier to digest. When something breaks, it’s much easier to identify what changed because the associated commit is small.
Code has to be self-testing
For the project’s sanity, main needs to remain healthy. That requires a well-tested codebase where tests run automatically as part of the pipeline. When main breaks, the team is encouraged to write tests to cover the missing scenarios. Testing becomes a first-class citizen rather than an afterthought.
Code is always deployable
When main is healthy, we know the code is always ready to go. Using feature flags, we can selectively expose features to users while hiding work that is still in progress. This means that when a hotfix or vulnerability patch is required, it’s clear where to make the change and we can get it into production quickly.
Code is understandable
CI encourages us to have one version of the code at any time (small in-flight changes from the development team aside). This means the team doesn’t need to maintain a mental model of months of diverging branches. Instead, there is a single source of truth where anyone can clone the repository and quickly understand the state of the codebase.
Admittedly, CI won’t always be the right fit for every project or team. If a team cannot match the integration frequency CI expects, it will be difficult to maintain. Teams also need to be invested in the process and hold themselves accountable to the delivery standards required.
It may feel like a significant change in how you work—because it is. But the benefits quickly pay for themselves. I often stress that this isn’t a new concept. Teams and leaders have been advocating for this approach for years, and most of the “but how would I…?” questions already have well-established answers.
Give it a try. In my experience, once teams embrace this way of working, they rarely want to go back.
Further Reading
As mentioned, many leaders in the technical world have been writing about this topic for a while. Here is a collection of sources that have inspired my thoughts here:
