release-engineering

Release Engineering

Turn a release into a sequence of evidence-backed decisions rather than one irreversible event.

Build the release contract

Record the artifact/version, environments, owner, change scope, affected users, data or contract changes, dependencies, risk class, maintenance window, and success metrics. Use release-record.md for the go/no-go and rollout record.

Establish gates

Require checks proportional to risk: build and tests, contract and migration proof, security findings, performance budgets, smoke paths, accessibility or visual checks, artifact signing/provenance, monitoring, and a tested recovery path. A green generic pipeline is not proof of the release's critical behavior.

Roll out safely

1. Separate deployment from exposure with a flag or routing control when practical.
2. Start with internal, shadow, canary, or low-percentage traffic.
3. Compare errors, latency, saturation, business outcomes, and support signals against a pre-release baseline.
4. Promote only after the observation window and all gates pass.
5. Roll back or disable immediately when a predefined threshold is crossed.
6. Verify recovery, communicate status, and preserve the timeline.

For canaries and production observation windows, use post-deploy-verification.md. Confirm the deployed build marker, run critical browser journeys through browser-testing, and record each promote, hold, or rollback decision against fresh baseline evidence.

Use immutable artifacts across environments. Keep release credentials out of logs and command lines. Require explicit authority for production mutation.

Close the release

Verify critical paths after deployment, monitor delayed jobs and regional effects, remove stale flags and compatibility paths on schedule, update release notes, and create owned follow-ups for non-blocking debt. Never substitute a successful deployment command for an observation window. Use incident-response if live impact begins and safe-migrations for stateful cutovers.