Technical Practices

In one sentence

Chapter 4 of Accelerate pivots from "what to measure" to "what to do": it decomposes continuous delivery from a slogan into a set of measurable, checkable capabilities — comprehensive configuration management, continuous integration, trunk-based development, test automation and test data management — and shows statistically that these capabilities drive delivery and organizational performance. More surprisingly, they also lower burnout and deployment pain and improve culture, forming a loop where practice and culture reinforce each other.

Glossary

Where it sits

This is Chapter 4 of Part I ("What We Found"). It follows Chapter 2 (the four key metrics, which made delivery performance measurable as an outcome) and Chapter 3 (the Westrum model, which made culture measurable), and leads into Chapter 5 (architecture) and Chapter 6 (integrating infosec). The earlier chapters answered "how do we know whether we're any good"; this is the first chapter that answers "so what do we actually change" — and it is the direct ancestor of DORA's later capability model.

The problem this chapter solves

The first three chapters put the conclusions on the table: speed and stability move together, performance is measurable, culture is measurable. But an engineering leader closing the book still doesn't know what to change on Monday morning. Continuous delivery is a word everybody uses, and "we do CD" carries almost no information — does having a pipeline count? Does having a CI server count?

What happens if you don't decompose it? Transformation degenerates into one of three familiar forms of spinning: buying tools (Jenkins is installed; trunk is red every day and nobody stops), setting a KPI ("deploy weekly," so the team batches ten changes into one deploy to satisfy the target), and climbing maturity levels (the approach Chapter 1 already demolished — ticking template boxes with no link to outcomes). Money spent, meetings held, metrics flat.

So the chapter does two things. First, it breaks CD into specific capabilities that can be measured and changed. Second, it answers "is it worth it" with data — because CD has genuine costs: automated tests must be written and maintained, the long-lived branching flow the team is comfortable with has to be dismantled, environment management has to be rebuilt. If all that bought was a bit of speed, most organizations wouldn't pay. The chapter's answer is that it buys considerably more than speed.

The core material, in depth

1. What continuous delivery actually means: two outcomes, five principles, three foundations

The authors define CD by outcomes, not by tooling. To claim you're doing CD, both of these must hold:

• Software is in a deployable state throughout its lifecycle — and the team treats keeping it deployable as a higher priority than working on new features. When the build goes red, everyone stops and fixes it first. That's the real test.
• Anybody can get fast feedback on quality and deployability, at any time — not just a release engineer who knows whether today's build is shippable, but everyone, continuously.

Underneath sit the five principles from Continuous Delivery: build quality in, work in small batches, let computers do repetitive work while people solve problems, relentlessly pursue continuous improvement, and make everyone responsible. And three foundations: comprehensive configuration management, continuous integration, continuous testing. This chapter's contribution is pushing all of it down into capabilities that can be measured in a survey and tested statistically.

2. Comprehensive configuration management: even the shape of the machine goes in the repo

For configuration management, the survey asks whether four things are all in version control: application code, system configuration (how a machine is built and what's on it), application configuration (per-environment parameters and switches), and build and configuration scripts. The test is blunt: can you rebuild an environment from scratch using only what's in the repository — not from a senior colleague's memory, and not from one server nobody dares reboot?

Here is the chapter's first counterintuitive finding: keeping system and application configuration in version control correlates more strongly with delivery performance than keeping application code in version control. That sounds absurd — isn't code in version control table stakes? Precisely because it is: almost everyone does it, so that item has no discriminating power. What separates teams is whether the material that normally lives scattered across wikis, tickets and operators' heads gets the same treatment. This is also why "infrastructure as code" later grew into a discipline of its own.

3. CI and trunk-based development: turning integration back from an event into a state

CI asks that every commit trigger a build and a round of automated tests, and that a failing build be the team's highest priority — nothing new gets stacked on a red trunk until it's fixed. The product is unglamorous: a shared codebase that always compiles and is always testable.

Trunk-based development is CI's precondition, and the chapter gives it three operational criteria (later carried forward by DORA):

• fewer than 3 active branches alive in the repository at once;
• branches and forks live less than a day before being merged to trunk;
• the team rarely or never has code freezes or integration phases — no stretch of days where nobody may check in because a merge is underway.

Note this is not "no branches allowed." Cutting a feature branch and merging it the same day complies fully; what the data condemns is the long-lived branch. Why are long-lived branches so expensive? Merge conflict cost scales roughly as "the surface you changed × the surface everyone else changed" — both grow linearly with time, so conflict grows with the square of it. Skip a day and the conflict is a few lines; skip three months and it's an integration campaign that needs a dedicated coordinator, resolved by people who no longer remember why either side was written that way. What small batches really do is bend that quadratic curve back to something near linear.

4. Test automation: who writes them discriminates more than whether they exist

This is the most valuable section of the chapter and the most frequently misquoted. The research didn't stop at "do you have automated tests" — nearly everyone answers yes. It teased out three finer conditions, and those are the real dividing line:

• The tests are reliable. When they pass, the team is confident the software is releasable; when they fail, that indicates a real defect. Those two are one statement seen from both sides: once red is frequently false, red stops being a signal, people re-run and then ignore it, and the value of the whole automation collapses to zero.
• Developers can run them themselves. Developers can reproduce failures on their own machines and get results quickly, rather than queueing for a once-a-night build. When feedback takes days, people batch up changes before testing — and the batch is large again.
• Developers create and maintain the acceptance tests themselves. This is the crucial one.

On that last point the chapter delivers a finding many organizations find uncomfortable: automated tests created and maintained primarily by a QA team or an outsourced party are not correlated with delivery performance. Note the calibration — "did not produce a performance gain," not "harmful," and not "you don't need testing professionals." Three mechanisms all make sense. First, testability is designed in: developers who don't write tests never restructure code to be testable. Second, the feedback loop is severed: when tests belong to another team, the red light never reaches the person who can fix it. Third, tests degenerate into a gate ritual — written to get past a checkpoint rather than to expose design defects.

Its companion capability is test data management: the data your tests need is available on demand, test data doesn't constrain what tests you can run, and preparing it doesn't require significant manual work. It is routinely ignored, and it is routinely the real reason a team's acceptance suite "can only run once, overnight."

5. The real payoff: not just speed, but people and culture

If the chapter only proved "CD makes you ship faster," it would be an empirical appendix to Continuous Delivery. Its heavier blow is this: continuous delivery also predicts a set of human outcomes — stronger identification with the organization (people say "we" about the company), lower deployment pain (no dread, no overtime, no praying before a release), lower burnout, and a more generative Westrum culture.

And the arrow runs both ways: technical practices improve culture, and better culture makes the practices easier to sustain. Chapter 3 said culture is hard to change; this chapter hands you the lever — you don't have to start with an all-hands about mindset. Unblock the trunk, make the tests trustworthy, and the culture score moves on its own. It is the most actionable causal claim in the book.

Key trade-offs and choices

Every practice here sounds obviously right, and every one has a real cost. The choice is not "should we," it's which one first, and which bill do we pay first, given our constraints.

Table 1 · Long-lived feature branches (GitFlow style) vs trunk-based development

Table 2 · Test automation: who writes them, and at what layer

Table 3 · Applying the chapter's principles under different delivery constraints (an extrapolation; the book does not enumerate these formats)

One practical ordering rule: if you can only do one thing first, fix the reliability of your tests. Trunk-based development, daily deploys, fast rollback — every other practice stands on the foundation of "green can be believed." Push daily merging while that foundation is soft and you'll get a permanently red trunk, followed by the whole team retreating to long-lived branches.

Why it matters / in real systems

This chapter mattered because it took a pile of practices that had been the folklore of senior engineers and, for the first time, tested them inside a statistical framework. Everything you'd hear as the standard answer at any company today — everything in Git including infrastructure as code, a pipeline on every commit, small PRs merged the same day, feature flags decoupling release from deploy, automated tests owned by the people writing the code — traces back here. It is also the direct source of DORA's capability map, now maintained as a public reference teams use to assess themselves.

And that catch-all interview question — "how do you release?" — this chapter is the marking scheme: Can trunk ship right now? How long do branches live? Who writes the acceptance tests? Does a red build get fixed the same day? Can an environment be rebuilt from the repository? Anyone who can't answer is still saving up big releases.

Common mistakes and open arguments

• Reading trunk-based development as "no branches allowed." What it objects to is branch lifetime, not branching. A feature branch merged the same day complies fully, and the short-lived release branches browsers and mobile teams cut from trunk are entirely compatible with it.
• Equating continuous delivery with continuous deployment. CD requires that you can ship at any time; whether every change actually goes to production automatically is a separate business decision. Conflating them convinces regulated teams the whole thing is irrelevant to them.
• Treating CD as a tool to purchase. Installing a pipeline is not doing CD — the test is whether trunk is shippable right now and whether a red build stops the team. A pipeline nobody fixes is decoration.
• Reading "QA-written tests aren't correlated" as "we don't need QA." The finding is about ownership sitting with developers, not about eliminating testing professionals; the specialists' value shifts toward exploratory testing, testability design and quality coaching.
• Reading "not correlated" as "harmful." The research observed no performance gain — not that those tests have no value. That distinction is a discipline of reading statistical claims.
• An honest note on methodology (also the book's most common criticism): the findings come from a voluntary industry survey with self-reported measures and self-selection bias. The authors support directional claims with latent-variable modeling and inferential predictive analysis, which is genuinely stronger than "correlation isn't causation" — but it is still not a randomized controlled trial. Quoting the book's "predicts" as though it were a law of physics is over-reading it.
• Period limits: written in 2018. GitOps, platform engineering, and the additional dimensions DORA's later reports added (reliability and operational performance, for instance) all extend the framework, and naturally aren't here. But the core — small batches, fast feedback, a green light you can believe — has not been overturned.

Takeaways