Day 169: Trunk-based Development - One Branch to Rule Them All

Trunk-based development is less about having one branch and more about refusing to let integration risk accumulate out of sight.

Today's "Aha!" Moment

Teams often hear “trunk-based development” and reduce it to a branching rule: work on main, keep branches short, merge quickly. That is true, but it misses the deeper reason the practice exists.

The real problem is delayed integration. Every hour or day that a change lives far from the main line, the team is effectively borrowing against future coordination and merge cost. Most of the time that debt stays invisible until it all arrives together: conflicts, broken tests, unexpected interactions, painful rebases, and last-minute release stress.

Trunk-based development is the delivery answer to that hidden accumulation. It says: integrate often, keep change sets small, get feedback early, and use techniques like feature flags or branch-by-abstraction so unfinished work does not require long-lived divergence from the main line.

For the warehouse company, imagine a pricing team and a checkout team both changing the same order flow. If each team stays on long-lived branches for a week, the merge becomes a mini-release event. If both integrate continuously in small steps, most risk is exposed while it is still cheap to understand and fix.

That is the aha. Trunk-based development is not a rule about Git purity. It is a way to reduce integration as a source of uncertainty in the delivery system.

Why This Matters

Suppose the company wants faster delivery with fewer merge crises and more reliable deploys. It has already invested in platform engineering and developer experience, but lead time still spikes near releases. Postmortems keep mentioning the same things:

• branches drifted too far
• integration happened too late
• feature work collided at the end
• code review and CI feedback arrived after too much context had piled up

This is exactly the situation trunk-based development tries to improve.

Long-lived branches create a false sense of local safety. Each engineer or team feels isolated from the main line, but the integration risk is merely postponed. The larger the batch, the more ambiguous the failure later becomes:

• which change caused the issue?
• which assumption drifted?
• what broke during merge rather than during coding?
• how much rollback now has to be coordinated?

Trunk-based development matters because it moves those questions earlier, when the system still has clear context and the change is still small enough to reason about.

It is also tightly connected to the previous lessons. If you care about flow, platform effectiveness, and delivery metrics, then reducing batch size and integration delay is one of the highest-leverage moves available.

Learning Objectives

By the end of this session, you will be able to:

1. Explain what trunk-based development is really optimizing - Understand it as integration-risk control, not merely branch policy.
2. Use the supporting techniques correctly - Recognize the roles of small batches, CI discipline, feature flags, and branch-by-abstraction.
3. Spot the main failure modes - Diagnose when “short-lived branches” are still too long or when unfinished work is leaking into production risk.

Core Concepts Explained

Concept 1: Small Batch Size Is the Delivery Primitive

The practical heart of trunk-based development is small batch size.

A small batch means:

• fewer moving parts per merge
• faster feedback from CI
• easier rollback or revert
• clearer understanding of what changed
• lower chance that multiple unrelated issues get bundled together

This is why branch duration is only a proxy. A branch that lives for a few hours but contains a huge, tangled change can still create a lot of risk. A branch that lives briefly and carries one focused step of a larger change is much healthier.

For the warehouse platform, consider a new pricing-rule engine. One team could build the whole thing on a long-lived branch and merge at the end. Or they could land it incrementally:

• add the new interface
• add a dormant code path
• route a tiny controlled slice through it
• expand once the system proves stable

Those steps feel slower locally, but they reduce system-level uncertainty dramatically.

That is why trunk-based development belongs in a lesson about delivery systems, not only source control. The size of the change batch often matters more than the branch naming policy around it.

Concept 2: Trunk-Based Development Needs Mechanisms for Incomplete Work

One reason teams resist trunk-based development is that real work is often incomplete for a while. The answer is not “merge broken code and hope.” The answer is to separate integration from exposure.

Two common mechanisms matter here:

• feature flags: integrate code paths without exposing them broadly to users
• branch by abstraction: insert a stable seam so old and new implementations can coexist while the change is completed incrementally

This is the basic pattern:

small change
   ->
merge to trunk
   ->
CI validates integration
   ->
exposure controlled separately

That distinction is critical. Integration says “this code coexists safely with the main system.” Exposure says “users or downstream systems now rely on it.” Trunk-based development pushes for early integration, not reckless exposure.

This is also why strong CI discipline is non-negotiable. If teams merge frequently but the main line is unstable, the whole model collapses. The trunk must stay trustworthy enough that integrating into it remains the safest path, not the riskiest.

Concept 3: The Main Failure Modes Are Hidden Long Branches and Weak Trunk Health

Teams sometimes say they are doing trunk-based development because their branches live “only” two or three days. In practice, that can still be very long if the team deploys frequently or if many changes are overlapping in the same areas.

Common failure modes include:

• “short-lived” branches that still accumulate too much drift
• feature flags that become long-term dead complexity
• CI that is slow or flaky, so frequent integration becomes painful
• code review processes that delay merges long enough to recreate batch buildup
• a trunk that is unstable, making developers afraid to integrate early

This is why the system has to be designed around the practice:

• fast, trusted CI
• clear ownership for fixing broken mainline states
• disciplined use of flags and cleanup
• review processes that preserve small-batch flow

If those supports are missing, teams will naturally drift back toward larger isolated work. The lesson is not “engineers lack discipline.” The lesson is that the delivery system is still making delayed integration feel safer than continuous integration.

Troubleshooting

Issue: The team claims to use trunk-based development, but merges still feel risky and painful.

Why it happens / is confusing: Branches may be shorter than before, but the actual batch size is still large or the trunk is not trustworthy enough.

Clarification / Fix: Measure change size, CI feedback time, and time-from-first-commit-to-merge. The issue is often hidden accumulation rather than the branch count itself.

Issue: Engineers worry that trunk-based development means exposing unfinished features.

Why it happens / is confusing: Integration and release are being mentally collapsed into one step.

Clarification / Fix: Use feature flags or branch-by-abstraction so code can be integrated early while exposure remains controlled.

Issue: Teams try to merge frequently, but everyone hates the process.

Why it happens / is confusing: CI may be too slow, too flaky, or too unreliable, which makes early integration emotionally and operationally expensive.

Clarification / Fix: Improve trunk health first. Frequent integration only works when the main line provides fast, trustworthy feedback.

Advanced Connections

Connection 1: Trunk-Based Development <-> DevEx Metrics

The parallel: Smaller batches and faster integration should show up as better flow metrics, lower merge pain, and shorter lead times.

Real-world case: If lead time remains high despite “short branches,” the real bottleneck may be CI or review latency rather than branching policy alone.

Connection 2: Trunk-Based Development <-> Feature Flags and Progressive Delivery

The parallel: Flags let teams decouple integration from exposure, which is one of the main enablers of trunk-based delivery at scale.

Real-world case: A team can merge incomplete infrastructure for a new pricing path safely if activation remains controlled and observable.

Resources

Optional Deepening Resources

• [SITE] Trunk Based Development
  • Link: https://trunkbaseddevelopment.com/
  • Focus: Use it as the primary reference for the practice, its rationale, and common supporting techniques.
• [SITE] DORA Guides
  • Link: https://dora.dev/guides/
  • Focus: Connect branch and integration practices to delivery outcomes such as lead time and deployment performance.
• [SITE] Team Topologies
  • Link: https://teamtopologies.com/
  • Focus: Think about how team boundaries and interaction patterns either support or undermine small-batch flow.
• [SITE] Google SRE Workbook
  • Link: https://sre.google/workbook/table-of-contents/
  • Focus: Use it to connect safe change, rollback, and release discipline to reliable operations.

Key Insights

1. Trunk-based development is really about integration risk - The Git policy matters less than the constant reduction of hidden batch size.
2. Early integration requires mechanisms for unfinished work - Feature flags and branch-by-abstraction let teams integrate safely before full release.
3. The trunk must be healthy enough to trust - Fast, reliable CI and disciplined cleanup are part of the practice, not optional extras.

Knowledge Check (Test Questions)

1. What problem is trunk-based development mainly trying to reduce?

   • A) The number of files in the repository.
   • B) Accumulated integration risk caused by large or delayed merges.
   • C) The need for any code review.

2. Why are feature flags important in this model?

   • A) They let teams avoid integrating code entirely.
   • B) They help separate integration into trunk from exposing behavior to users.
   • C) They replace CI.

3. What usually breaks trunk-based development first?

   • A) Too many comments in pull requests.
   • B) A slow or unreliable mainline feedback system that makes early integration feel unsafe.
   • C) Having fewer than ten engineers.

Answers

1. B: The practice exists to stop risk from building up silently in long-lived, high-batch divergence from the main line.

2. B: Flags allow safe early integration while release timing remains under control.

3. B: If the trunk is not healthy and feedback is slow or flaky, engineers will naturally avoid integrating often.

← Back to Learning