deployment-pipeline-design

Structure the pipeline as build, test, security scan, staging deploy, then production canary. Use Argo Rollouts with stepped traffic weights (10%, 25%, 50%, 100%) and an AnalysisTemplate that checks Prometheus error-rate metrics before each promotion step.

Blue-green switches all traffic instantly between two full environments, giving instant rollback but doubling infrastructure cost temporarily. Canary shifts traffic gradually to the new version while validating real-user metrics, requiring Argo Rollouts or a service mesh.

Argo Rollouts stalls when the AnalysisTemplate query returns no data, leaving the analysis inconclusive indefinitely. Set inconclusiveLimit on the metric so the rollout fails fast instead of hanging, and verify the Prometheus query returns results.

Use the expand/contract pattern: add nullable columns in one release, backfill and switch reads in the next, and drop old columns only after old code is retired. Keep versioned undo scripts alongside forward migrations and use CREATE INDEX CONCURRENTLY in PostgreSQL.

The pipeline is likely hitting a shallow endpoint that returns 200 even when dependencies are down. Replace it with a deep readiness check that verifies the database, cache, and queue connections before promoting traffic.

Yes, the references include full pipeline configurations for all three platforms, covering reusable workflows, environment protection rules, manual approval gates, OIDC cloud authentication, and canary strategies with pre-deployment validation.