DevOps: map a change from commit to recovery

Operational decision

For a ledger API, draw the path from a merged commit to a tested artifact, a production deployment, and the first signal that the new version works. Record who can stop the release and how they restore service if the new code fails. Measure change lead time and deployment frequency alongside change failure and recovery; a fast pipeline that produces repeated incidents is a poor pipeline. DORA now also tracks deployment rework, so treat metric definitions as versioned operational contracts. Start with one service and its actual event timestamps. The shell sketch below turns a release record into an explicit set of checks; connect each check to the real systems used by the team. A process diagram without a restore step is unfinished.

release_id=ledger-2026-10-01-47
check_artifact_digest "$release_id"
check_test_result "$release_id"
check_deployment_health "$release_id"
record_recovery_owner "$release_id"

Cost and verification

Every gate adds wait time, but gates that detect a costly failure before production can reduce total recovery work. Capture the time spent queued, testing, and waiting for approval separately; otherwise a single lead-time number hides the bottleneck. The commands are a workflow sketch, not stock shell utilities. In a real pipeline, make a failed check stop promotion, persist the evidence, and avoid granting the check process deployment credentials it does not need.

Common Mistakes

• Do not equate a green build with a healthy release.
• Do not optimize deployment frequency while ignoring failed deployments.
• Do not rely on an undocumented person as the recovery plan.

Connected lessons

• DevOps Tutorial
• DevOps feedback loops, ownership, and release boundaries
• Continuous integration: test the merge candidate
• SLOs and error budgets: turn reliability into a decision