Bereitstellung prüfen und wiederherstellen

Deployment Verification & Recovery

A green CI build proves only that the code compiled and passed synthetic tests—it does not prove the release works in the target environment. Every deployment requires live health verification and a pre-planned recovery path.

Liveness vs. Readiness vs. Startup Probes

Never wire all health checks to a single endpoint that indiscriminately restarts healthy containers when a downstream dependency blips:

Post-Deploy Smoke Checks & Progressive Rollout

1. Automated smoke verification:
   • Immediately after deployment, verify:
     1. The deployed /version or health metadata matches the expected git_sha.
     2. At least one representative end-to-end user or API read path succeeds (200 OK with valid payload schema).
     3. Error rates (5xx), startup crash loops, and p95 latency remain within baseline thresholds during the observation window.
2. Zero-downtime rolling / blue-green / canary cutover:
   • Keep old instances serving traffic until new instances pass readiness and smoke checks.
   • During cutover, stop sending new requests to retiring instances, wait for in-flight HTTP requests and active jobs to finish (SIGTERM drain period), and only then terminate the old processes.

Rollback vs. Roll-Forward Decision Matrix

When a release degrades production, prioritize restoring service over debugging in place—while accounting for data and schema state: