Post-Release Verification Workflow

Verify a release after shipping with production smoke tests, metric comparisons against baseline, and a structured closeout report.

beginner~20 minreleaseverificationobservability

Objective

Confirm the release behaves in production as intended across function, performance, and business metrics, then close the release formally.

Environment

A freshly deployed release in production
Baseline metrics captured before the release
Smoke tests runnable against production safely

Steps

1. Run production smoke suite

Execute the read-only and transaction-reversible smoke tests against production endpoints immediately after deploy.

Expected state: All smoke checks pass on the new version within minutes of shipping.

2. Compare core metrics to baseline

Overlay error rates, latency percentiles, and key business metrics against the pre-release baseline for the first hours.

Expected state: No metric regresses beyond its pre-agreed tolerance.

3. Verify the release claims

Check specifically what the release said it delivers: new endpoint responds, the fixed bug no longer reproduces with the production scenario.

Expected state: Each release-note claim has a verification result attached.

4. Watch the long-window signals

Extend observation through the first daily cycle to catch time-dependent behavior: cron jobs, cache cycles, batch windows.

Expected state: The first nightly batch and daily peaks pass without anomalies attributable to the release.

5. Close out with a report

Publish a short release verification report: claims verified, metrics versus baseline, anomalies and their disposition, then formally close the release.

Expected state: The release ticket closes with the report linked, and lessons feed the next plan.

Expected outcome

Every release closes with evidence that its claims hold in production and its metrics match baseline, with anomalies dispositioned rather than forgotten.

Verification

The release record contains the smoke results, metric comparison snapshots, per-claim verification, and a closed report; no release closes without them.

Cleanup

Archive baseline snapshots and reports with the release artifacts.

The release is not done when it deploys

A green pipeline proves the artifact; only production proves the release. Smoke tests, baseline comparison, and claim-by-claim verification turn shipping into a closed loop, and the report makes the evidence permanent.

v1.8.0 post-release verification (T+2h)
smoke:      14/14 PASS (auth, search, checkout, refund)
claims:
  coupon engine        VERIFIED (code SAVE10 -> -10%)
  rounding fix         VERIFIED (3-decimal currency)
metrics vs baseline (7-day):
  error_rate   0.31% vs 0.29%  (tol 0.5%)  OK
  p99 latency  412ms vs 405ms  (tol 10%)  OK
  checkout cvr +1.8% rel                OK
anomalies: none
first nightly batch: PASS (03:10Z)
status: RELEASE CLOSED

Verify claims, not just health

A release can be perfectly healthy while delivering nothing it promised: the feature flag off, the endpoint routing wrong. Walking the release notes as a checklist in production is the only direct test that the release is what it says it is.

The long window catches the time bombs

Most post-deploy checks stop after an hour, which is exactly when they miss the nightly batch, the cache expiry cycle, and the morning peak. Extending verification through one full daily cycle costs nothing in effort and catches the failures that scheduled traffic reveals.