Trunk-Based Development at Scale: What Actually Changes When You Drop Long-Lived Branches

Every year the DORA research programme names trunk-based development as one of the practices that distinguishes elite delivery performers. The correlation is stable across a decade of reports: teams that integrate to a single shared branch at least daily ship faster, recover faster, and carry less change-failure risk than teams living on long-lived feature branches. And yet outside a handful of FAANG-scale engineering orgs, almost nobody does it.

The gap is not ignorance. Most engineering leaders have read the research and agree with it. The gap is that trunk-based development is not a branching policy you can announce on a Monday — it is the visible tip of four underlying capabilities. Delete your long-lived branches without those in place and you get exactly what your engineers fear: half-finished features leaking into production, a red trunk that blocks everyone, and a mob demanding the old workflow back within a fortnight.

What follows is what actually changes, and what has to be true first.

Finding 1: The blocker is prerequisites, not discipline

When a trunk-based rollout fails, the post-mortem usually blames culture — "the team wasn't disciplined enough to keep the build green." That is the wrong diagnosis. The DORA capability model is explicit that trunk-based development co-depends on continuous integration and a fast, reliable test suite. If merging to trunk can leave the build broken for hours because your test suite takes 40 minutes and is flaky, then integrating daily is genuinely reckless. The discipline problem is downstream of a tooling problem.

The honest prerequisite list is short but non-negotiable:

• Feature flags, so incomplete work can merge to trunk without being exposed to users
• Contract-first APIs, so front-end and back-end can integrate against an agreed shape before either side is finished
• PR-level quality gates that run in single-digit minutes and are trusted enough that a green build genuinely means safe to merge
• Leadership willing to hold the line through the 6–8 weeks it takes for the new workflow to feel normal

Action: Before you touch branching policy, measure your current PR-to-merge cycle time and test-suite duration. If a full pre-merge check takes longer than about ten minutes, or your flaky-test rate is high enough that engineers routinely re-run to get green, fix that first. Trunk-based development on top of a slow, untrustworthy pipeline just moves the pain from merge day to every day.

Finding 2: Feature flags are the actual mechanism, not a nice-to-have

The reason long-lived branches exist is that teams need somewhere to hide unfinished work. Trunk-based development removes the branch but the work is still unfinished — so the hiding place has to move into the running application. That is what feature flags are for. Google and other large trunk-based shops describe this as branch by abstraction: you merge incomplete code behind a flag that is off in production, and you keep the trunk deployable at all times.

This is where most rollouts underestimate the engineering effort. A robust flag setup means a flagging service or library, a convention for naming and owning flags, a lifecycle to remove dead flags before they rot into permanent conditional spaghetti, and testing that exercises both flag states. Skip the lifecycle discipline and within a year you have hundreds of stale flags and a codebase nobody can reason about — you have traded merge-hell for flag-hell.

Action: Treat flags as first-class code with an owner and an expiry. Add flag age to your engineering dashboards and set a policy that any flag older than a release cycle either goes to 100 per cent and gets deleted, or gets an explicit renewal decision. A short flag lifespan is the single best predictor of whether trunk-based development stays healthy.

Finding 3: The quality gate has to be trusted before anyone will keep the trunk green

The cultural expectation of trunk-based development — "you don't break the build" — only holds if the build tells the truth. If the pipeline is slow, engineers batch changes to amortise the wait, which recreates large risky merges. If it is flaky, they learn to ignore red, which defeats the entire point of shared integration. The behaviour you want is downstream of a gate people believe.

That belief is earned, not asserted. It means a test suite that actually catches the regressions it claims to, not one that is merely large. A suite can have thousands of tests and still let real defects through if the tests assert on the wrong things or cover the wrong paths — which is why measuring test effectiveness (does a test actually fail when the behaviour it guards is broken?) matters more than raw coverage percentages. This is where an outside pod is often more use than more headcount: a qualified engineering pod coming into a codebase installs the fast, trustworthy gate — parallelised tests, contract checks, flag-state coverage, effectiveness measurement — as a day-one deliverable rather than a someday-refactor, and does it alongside your engineers so the practice stays after they leave.

Action: Pick your ten most business-critical flows and verify that a deliberately broken version of each actually turns the pipeline red. If any of them stay green, your gate is theatre, and no branching change will help until that is fixed. Publish the result to the team — visible evidence that the gate works is what earns the discipline you need.

What 90 days looks like in a real codebase

Sequencing matters more than ambition. A realistic path for a 50–500-engineer org is roughly:

• Weeks 1–3: instrument the pipeline. Get pre-merge checks under ten minutes, quarantine flaky tests, and establish test-effectiveness measurement on the critical flows.
• Weeks 3–6: introduce a feature-flag service and a naming-plus-lifecycle convention on one or two teams. Move contract definitions ahead of implementation for the APIs those teams share.
• Weeks 6–10: shorten branch lifetimes on the pilot teams to under a day, integrating behind flags. Keep the old workflow available as a fallback but track how often it is used.
• Weeks 10–12: review the evidence — cycle time, change-failure rate, flag age — and decide whether to roll the pattern to the next teams.

The reason this takes a senior team rather than a policy memo is that every step touches production risk, and the person making the trade-offs needs to have made them before. Junior-heavy rollouts tend to get the mechanics — flags, gates, contracts — technically correct but miss the judgement calls: which flows are critical enough to gate hard, which flags are safe to ship dark, when to hold the line and when a team genuinely isn't ready. A senior engineering pod delivering into your codebase carries that judgement in, and the delivery and CI/CD work is done as evidence against your bar — change-failure rate, effective test coverage, cycle time — not as a slide claiming success.

The honest caveat

Trunk-based development is not free and it is not universal. If your product has genuine hard release boundaries — regulated firmware, on-premise software with quarterly customer upgrades — the calculus differs, and forcing daily integration can add ceremony without payoff. The point is not to chant the DORA line. It is to recognise that when trunk-based development works, it works because the four prerequisites are in place, and when it fails, it fails because they aren't. Fix the prerequisites and the branching strategy mostly takes care of itself.

Anystack works this way in practice: a small senior pod delivers into your codebase, installs the fast trustworthy gate and the flag lifecycle first, and shortens branch lifetimes only once the evidence says the safety net will hold. The measurement — test effectiveness, change-failure rate, cycle time — stays with you after the engagement, so the practice survives the pod leaving.