SOP: A safe pre-deployment change window

Scope: decide what is changing

A release plan should identify the exact revision, target environment, expected user-visible change, known dependencies and the people authorized to approve it. Treat a documentation release and an infrastructure migration differently: the blast radius controls the depth of review.

Record an agreed change window and an explicit no-go condition before anyone presses deploy. A passing CI job is not proof that a database migration or a live endpoint is healthy.

Preflight: access, backups and evidence

Check that deployment credentials are scoped, not expired and not accidentally available to untrusted jobs. Verify the most recent restore evidence for relevant data, and test who can execute a rollback or forward fix. Preserve current runtime and dependency versions for comparison.

• Approved target commit SHA and artifact identifier
• Tests on that final revision and a reviewed change diff
• A recent, restorable data backup if state is affected
• Known application health endpoints and expected metrics
• Rollback or forward-fix decision owner and escalation contact

Approval gate and go/no-go decision

The approving person should see what will change, why, how risk is bounded and what would trigger stopping. Separate the operator’s ability to trigger deployment from the reviewers’ approval when practical. A named owner should have a realistic way to observe the release.

Deployment observation

Record a deployment ID and timestamp, monitor primary health signals and watch for unusual error spikes. A production deployment may return successfully while the real hostname still serves an old build or misconfigured endpoint.

curl --fail --location --max-time 15 -I https://app.example.com/# Record the release SHA from an authorized version endpoint.# Follow with a permitted end-to-end smoke test.

Handover, rollback and closeout

If health diverges from the baseline, use pre-agreed stop criteria. Reverting application code without checking database compatibility can worsen an incident. Close the change only after checking users’ critical paths, capturing evidence and communicating the final state.

• Actual deployed revision and approval evidence
• Smoke-test outcomes and monitored signals
• Any incident, deviation or deferred cleanup
• Operator and recipient handover acknowledgement

FAQ: when should the change stop?

Stop if the reviewed SHA no longer matches the deployed artifact, if an essential dependency is unknown, if rollback is not possible for a risky migration, or if metrics reveal unexpected user harm. A formal time window is not permission to ignore evidence.