Two days to two hours

When people hear "releases went from two days to two hours," they assume the work was in the pipeline — parallelizing steps, caching builds, faster runners. That was maybe a fifth of it.

The real work was killing the queue. A release took two days because it was a batch: dozens of changes accumulated until someone declared a release window, and then a 20-person QA team descended on the pile. The pile was the problem. Every change in the batch multiplied the blast radius of every other change, so verification had to be exhaustive, so releases were expensive, so we batched more changes per release. A perfect flywheel, spinning the wrong way.

Single-commit CI/CD breaks the loop at the batch. One commit, one ephemeral environment, one verification pass scoped to what actually changed. The environment exists for exactly as long as the verification does. Nothing waits for a window because there is no window.

Two things I'd tell anyone attempting this:

• The ephemeral environments are the hard part and the point. If your change can't be exercised in a real, disposable copy of the system, your "verification" is a code review with extra steps.
• The QA team doesn't disappear; the queue disappears. Judgment moves to where it compounds — test design, edge-case hunting — instead of being spent walking the same happy path forty times per release.

The pipeline got faster because the unit of release got smaller. Speed was a consequence, not a goal.