Continuous Integration and trunk-based development

Small batches, integrated to trunk many times a day. Long-lived branches accumulate divergence, and the longer they live the more painful the merge. Trunk-based development with feature flags inverts the model — and HP and Bazaarvoice show what happens at scale.

// optimize for the team, not the individual

// individual productivity

— Long-lived feature branches per developer.
— Big merges at the end ("merge hell").
— Trunk diverges fast; integration is a project.
— Devs feel productive in isolation; team flow stalls.

// team productivity

— Small batches merged to trunk daily.
— Merge conflicts found while context is fresh.
— Trunk always close to shippable.
— Slightly more friction per dev, vastly more throughput per team.

// the new definition of "done"

At the end of each development interval, we must have integrated, tested, working, and potentially shippable code, demonstrated in a production-like environment, created from trunk using a one-click process, and validated with automated tests.

// case study · hp laserjet firmware (2014)

Gary Gruver led HP's LaserJet firmware team. Goal: 10x the time spent on new functionality. They got there through CI + trunk-based development + automated testing on every commit + automated regression every 2 / 4 / 24 hours.

builds / day

1 → 10–15

commits / day

20 → 100+

regression time

6 wk → 1 day

dev time on innovation

5% → 40%

Bottom line: overall development costs −40%, programs under development +140%, cost per program −78%. The technical practices paid for themselves several times over.

// case study · bazaarvoice (2012)

Bazaarvoice migrated their large legacy codebase to CI + trunk-based development. The outcomes were the same shape as HP — dramatic increase in deploy frequency, dramatic drop in deploy failure rate, and a culture that started shipping in small batches by default. The general lesson: CI works even on big legacy codebases; you don't have to be a greenfield startup.

download Case study · Bazaarvoice CI (2012) · PDF ~500 KB

help Knowledge Check

Question 1/2

A team works on long-lived feature branches "to avoid breaking trunk." Merges take 2–3 days every two weeks. What does the DevOps Handbook predict?

// pick one to verify

help Knowledge Check

Question 2/2

HP's LaserJet team went from 5% to 40% of dev time spent on innovation. The other 60% used to be:

// pick one to verify

arrow_back mod-06 / overview mod-06 / deploy arrow_forward