This is a demo I built to help prevent staging and production from drifting apart before it causes a failed deployment.
Staging
v4.12.0 · a91f3c
MQ: healthy
Production
v4.11.2 · 7e2b10
MQ: healthy
Deployment Checklist
Push the release validated in Staging to Meridian Airways's Production environment at Toronto Pearson — Terminal 1 via the DevOps release pipeline.
Rollback: Redeploy the last known-good build (4.11.2) and re-run the configuration step.
Run the client-specific configuration script against SQL Server and verify the settings in the web client match Meridian Airways's requirements.
Rollback: Restore the previous configuration snapshot captured before this deployment.
Walk through the client's core operational workflow in Production to confirm it behaves as configured.
Rollback: Hold rollout and reproduce the failing workflow step in Staging before retrying.
Confirm the messaging queue is healthy and no errors are surfacing before handing the environment back to the client.
Rollback: If the queue is degraded, pause sign-off and escalate instead of releasing to the client.
Execution Log
No activity yet — complete or roll back a step to see the audit trail build here.
How it works
Each client site carries its own Staging and Production snapshot — version, SQL config fingerprint, and message queue status. A drift check runs on every client switch and flags the moment those two environments disagree, which is the exact failure mode behind most bad client rollouts: the build that worked in Staging isn't actually what's live in Production. The checklist itself enforces order — you can't sign off "Test client workflow" before "Deploy" has been marked complete — and every sign-off and rollback is timestamped and attributed, the same audit trail a real release pipeline in Azure DevOps would keep.