Quartz 4

Trunk-Based Development

2 min read

Core Principle

Trunk-based development is the practice of all developers committing to a single shared branch (trunk/main) at least once daily, with three or fewer active branches, no long-lived feature branches, and no code freezes or integration phases. It is a key enabler of continuous integration and, by extension, continuous delivery.

Why This Matters

DORA’s research (2016-2017 data and subsequent years) established that teams following trunk-based development achieve superior software delivery performance across all dimensions: delivery speed, stability, and availability. DORA defines continuous integration as “the combination of practicing trunk-based development and maintaining a suite of fast automated tests that run after each commit to trunk.”

Long-lived feature branches are the anti-pattern. They create invisible inventory (queued changes), increase merge conflict risk, delay feedback, and make integration a distinct “phase” rather than a continuous activity.

Evidence/Examples

DORA’s three performance indicators for trunk-based development:

  1. Three or fewer active branches in the repository
  2. Branches merged to trunk at least once a day
  3. No code freezes, no integration phases

Recommended practices:

  • Synchronous code reviews (pair programming or real-time review) over asynchronous PR queues
  • Comprehensive automated testing with fast builds (minutes, not hours)
  • Feature flags to decouple deployment from release
  • Small batch development (changes deployable in hours)

trunkbaseddevelopment.com provides the canonical reference.

Implications

  • Feature branching workflows (GitFlow and variants) are empirically inferior for delivery performance
  • The argument against trunk-based development is usually cultural (“what if someone breaks trunk?”), and the answer is: fast automated tests, small batches, and a culture that treats a broken trunk as an immediate fix, not a blame event
  • Trunk-based development requires infrastructure maturity: fast CI, good test coverage, feature flags

Questions

  • How does trunk-based development work in open-source projects with many external contributors who can’t commit directly to trunk?
  • What’s the minimum CI speed threshold where trunk-based development becomes practical?

Sources

Graph View

Backlinks