Define the release boundary
Before deployment, identify the exact artifact, configuration, migration set, feature flags, and external services that form the release. A passing build for a different commit is not evidence for the artifact being promoted.
The release record should connect approved requirements and QA evidence to that immutable build.
Prepare for failure before launch
A deployment plan needs health checks, logs, metrics, ownership, rollback or roll-forward steps, and thresholds that determine when action is required. These are product safeguards, not infrastructure trivia.
- Verify secrets and configuration without exposing them.
- Exercise migrations and recovery paths.
- Define health and business-success signals.
- Assign an owner for the launch window.
Production is another evidence source
Synthetic checks can confirm availability, while real telemetry shows whether people complete important journeys. Compare both against expected behavior and privacy constraints.
A release is complete when the new version is healthy, observable, and understood—not merely when the deployment command exits successfully.