Trunk-Based Development

Overview

Trunk-based development keeps all engineers working against one mainline. Branches, when used, last hours. The practice is a prerequisite for continuous delivery, and the DORA research links it to higher delivery performance.

How it works

Work is sliced into increments small enough to merge safely every day. Code merged but not ready is disabled by a flag or isolated behind an interface that still routes to the old implementation.

main: --o--o--o--o--o--o--o-->  (always green, deployable)
         \  /   \ /
          o      o      short-lived branches (under 1 day)

Pre-merge checks run unit tests and linting in minutes. Post-merge pipelines run slower suites and deploy. If main breaks, the rule is revert first and investigate second.

if flags.enabled("new-checkout", user):
    return new_checkout(cart)
return old_checkout(cart)

Pitfalls

• A slow test suite that makes small merges painful, pushing people back to long branches.
• Treating flags as permanent. Give each flag an owner and an expiry.
• Merging half-baked code with no way to turn it off.
• Big pull requests that wait days for review. Use pairing or small reviews.
• No automatic revert policy for a red main.
• Adopting it without trunk-quality safeguards such as required checks.

Key takeaways

• Merge small, merge daily, keep main releasable.
• Flags and branch by abstraction hide unfinished work.
• Fast, trustworthy tests are the enabling investment.
• Revert broken commits quickly.
• Retire flags promptly.