Trunk-Based Development at Scale: A Field Guide for Enterprise Teams

Trunk-based development (TBD) is one of those practices that sounds simple, generates enormous resistance, and then — once adopted — teams can't imagine working any other way. We've led the migration to TBD in four enterprise environments over the past two years. This is the field guide we wish we'd had.

What trunk-based development actually is

The core idea: all developers commit to a single branch (trunk/main) multiple times per day. Feature branches, if they exist at all, live for hours — not weeks. No release branches. No long-lived development branches that diverge from main until they become un-mergeable.

This sounds terrifying to teams used to GitFlow or GitHub Flow with long-lived features. The fear is understandable: what happens when half-finished code goes to production?

The answer is feature flags. Incomplete features are merged behind a toggle that is off in production. The code is deployed; the feature is not activated. This decouples deployment from release — a distinction that is more important than most teams appreciate.

Why enterprises resist it

In every enterprise we've worked with, the resistance to TBD follows a predictable script:

"Our features are too large to merge daily." This is usually true, and it is the actual problem TBD is solving. Large features are large because teams don't decompose them into independently deployable increments. TBD forces that decomposition. The discipline of keeping commits small and trunk-safe is not a constraint imposed on you — it is a skill that makes your code better.

"We have compliance requirements." Regulated industries often believe compliance requires long-lived release branches with formal review gates. This is almost never actually specified by the regulator. It's a historical interpretation that became policy. We've helped banking and healthcare clients implement TBD while maintaining full audit trails, change management records, and automated compliance checks.

"Our test suite is too slow." This is the real blocker more often than teams admit. TBD requires a fast CI pipeline — ideally under 10 minutes for the full suite. If your tests take 45 minutes, you can't commit to trunk multiple times per day without creating chaos. The solution is to fix the tests, not abandon TBD.

The migration path

We've converged on a four-stage approach:

Stage 1: Stop creating new long-lived branches

Before tackling existing branches, declare a moratorium on creating new ones. New features go behind feature flags and merge to trunk within 48 hours or less. This builds the muscle without the upheaval of cleaning up existing state.

Stage 2: Implement feature flagging infrastructure

You need a feature flag system before you can TBD properly. This doesn't mean buying LaunchDarkly on day one. A simple database-backed flag service with a local override mechanism is enough to start. Evaluate managed services once you understand your actual flag volume and targeting needs.

Stage 3: Accelerate CI

Run your test suite in parallel. Identify the tests that are slow and either fix them or move them to a nightly suite. The goal is a pipeline that completes in under 10 minutes. This is not optional for sustainable TBD.

Stage 4: Retire the existing branches

Systematically work through existing long-lived branches. For each one: what is the smallest mergeable slice? Merge it behind a flag. Repeat. Accept that some branches will be partially discarded — the code in them was written for a context that no longer exists.

What actually changes

The visible change is the branch list. The real change is how your team thinks about work.

Stories get smaller. When the merge window is 24–48 hours, engineers naturally decompose features into smaller, independently shippable units. This is almost universally a quality improvement — smaller changes are easier to review, easier to test, and easier to roll back.

The codebase stays healthier. Merge conflicts are resolved when they're trivial, not after weeks of divergence when they've become architectural. Code review happens on increments that reviewers can actually understand, not on 3000-line PRs that nobody reads carefully.

Deployments become boring. When you deploy 10–20 small, well-tested changes per day instead of one large release per sprint, individual deployments stop being events. The risk is distributed and small. Rollbacks, when needed, are surgical.

"We went from four releases per year, each requiring a week of stabilisation, to deploying fifteen times a day. The stabilisation week just stopped existing." — Engineering Lead, MENA telecom client

The failure modes

TBD can fail, and when it does, it usually fails in one of these ways:

Feature flags accumulate and are never cleaned up. Flags are technical debt. Every flag that isn't removed after its feature launches is a conditional branch in your code that will still be there two years later. You need a flag lifecycle process — flags get an expiry date when they're created, and expired flags trigger a cleanup task.

Teams merge without passing tests. If the CI pipeline is slow and teams start merging with failing tests to "unblock" themselves, the main branch becomes unreliable. A red main branch undermines the entire model. Non-negotiable rule: the pipeline must be green before merge.

Management confuses deployment with release. Deploying code to production with a flag off is not releasing the feature. Finance and product teams sometimes struggle with this distinction. Invest time in explaining the model — the alternative is pressure to activate flags before they're ready.

Five things to take away

1. TBD forces the decomposition of large features into small, independently deployable increments — this is a feature, not a constraint.
2. Feature flags decouple deployment from release; this distinction is more strategically important than most organisations realise.
3. A CI pipeline that takes over 10 minutes is incompatible with sustainable TBD — fix the tests before you fix the workflow.
4. Flag lifecycle management is not optional. Flags need expiry dates and a cleanup process.
5. The main branch must always be green. One non-negotiable rule, enforced mechanically.