Engineering Practice
Putting it together: build a team delivery loop
Knowing the loop is not the same as running one. Stand up the whole delivery loop for a small team on a real (or realistic) service — CI gate, trunk-based development plus flags, review norms, on-call, and a postmortem-to-fix loop — then prove it works by driving an incident through it and watching DORA move in the right direction.
Turn the track’s mental model into a running system: a fast CI gate that makes frequent merging safe, flags that decouple deploy from release, lightweight review norms, an on-call path with a kill-switch, and a postmortem loop whose action items feed back upstream — all measured by the four DORA metrics together.
For a small service (2-3 components, your own or a starter), stand up the full delivery loop and the practice system around it — CI gate, trunk-based + flags, review norms, on-call, postmortem-to-fix — then prove the loop is intact by running a realistic incident end to end and showing DORA moves the right way.
- A reviewer can merge a small PR only when the CI gate is green; a forced red on any blocking step demonstrably blocks the merge.
- The risky change deploys to prod dark and is recovered by flipping the flag off — no rollback build — and the recovery time is recorded as MTTR.
- A before/after DORA snapshot under the same workload: lead time, deploy frequency, change-fail rate, and MTTR — measured from the dashboard/logs, not estimated.
- The flag inventory shows every flag has an owner, a removal ticket, and an expiry; the demo flag is closed out (completed → archived, branch removed) after the drill.
- The postmortem lists at least one owned, dated, tracked action item that ships a concrete upstream change (test / contract / flag default), and you can point to that change merged through the gate.
- Add a flag-debt guard to CI: fail the build (or open a ticket) for any flag past its expiry or with no owner, so flag debt cannot silently accumulate.
- Add a change-fail-rate governor: an automated check that blocks raising deploy frequency further if CFR or MTTR regresses past a threshold, encoding 'optimize the loop, not one metric'.
- Run a property-based or contract test that catches a class of regressions a single example test would miss, and show it failing the gate on the deliberate bad change.
- Do a second incident drill where the fix is a contract assertion at a service boundary, and show the same defect can no longer reach trunk — proving the loop closed.
This is the loop you will run on every real team: a fast trustworthy CI gate makes frequent merging safe, trunk-based plus flags decouples deploy from release, review norms keep batches small and latency low, on-call with a kill-switch keeps any escape’s blast radius tiny, and a blameless postmortem with owned action items feeds the fix back upstream — all governed by DORA’s four metrics together. Building it once on a small service, and driving one incident through it end to end, is what turns the mental model into how your team actually ships.