Practice : Trunk-Based Development

Purpose and Strategic Importance

Trunk-Based Development (TBD) is a version control strategy where all developers commit to a single shared branch - typically main or trunk - with high frequency. This practice reduces integration friction, shortens feedback loops, and encourages continuous collaboration.

TBD is essential for teams aiming to improve deployment frequency, reduce cycle time, and eliminate complex merge conflicts. It supports CI/CD by ensuring all code changes are integrated early and often, enabling faster, safer delivery of value to users.

Without TBD, long-lived feature branches and delayed merges create risks: hidden conflicts, integration bottlenecks, and last-minute surprises before release.

Description of the Standard

  • All developers commit to a single shared branch (e.g. main) multiple times per day.
  • Feature development is performed using short-lived branches (e.g. < 1 day), merged via pull requests or direct commits with tests.
  • Long-lived branches (>1 day) are strongly discouraged and require explicit justification.
  • Integration is supported by CI pipelines that validate every commit.
  • Teams use feature flags, toggles, or branch-by-abstraction to manage incomplete work in production.

How to Practise This Standard (Playbook)

1. Getting Started

  • Align the team on using a single integration branch (main, trunk, or similar).
  • Configure CI to trigger builds on every commit to trunk.
  • Set expectations: commits should be small, frequent, and shippable.
  • Use pull requests or pair programming for visibility and quality.

2. Scaling and Maturing

  • Eliminate the need for long-lived feature branches by adopting feature toggles or modular design.
  • Use pre-merge validations (e.g. linting, tests) to prevent regressions on trunk.
  • Establish social contracts: broken builds stop the line, and everyone helps fix them.
  • Visualise commit frequency and lead time to encourage good habits.

3. Team Behaviours to Encourage

  • Commit early, commit often - don’t wait until “done.”
  • Review and merge changes continuously rather than in batches.
  • Prefer small, composable changes over big-bang features.
  • Optimise for team flow, not individual perfection.

4. Watch Out For…

  • Developers working in isolation on long-lived branches.
  • Merging changes without CI validation or tests.
  • Trunk becoming unstable due to uncoordinated or unreviewed commits.
  • Resistance to changing habits - TBD can feel risky at first.

5. Signals of Success

  • Trunk is always in a deployable state.
  • Teams rarely experience merge conflicts.
  • Engineers integrate changes multiple times per day.
  • Features are released via flags, not delayed merges.
  • Everyone understands the health and purpose of trunk.