deployment-pipeline-design

Multi-stage CI/CD pipelines separate build, test, staging, and production into distinct phases with manual or automated approval gates between them. Gates enforce policy checks and security scans before promotion, preventing unsafe code from reaching production while maintaining deployment velocity.

Blue-green maintains two identical production environments and switches traffic instantly; canary routes a percentage of traffic to the new version to catch issues early; rolling gradually replaces instances. Each strategy balances risk, rollback speed, and monitoring requirements differently.

Automated rollback monitors post-deployment health checks and metrics; if thresholds fail, the pipeline triggers an automatic revert to the previous stable version. Pair this with feature flags to disable problematic code without redeploying.

GitOps treats Git as the single source of truth for infrastructure and application state across environments. Commits trigger automated promotions through staging to production, with approval gates enforcing policy before each environment transition.

Deployment pipelines should include source code scanning, dependency vulnerability checks, artifact signing, and runtime security policies. Security scans run at build time; approval gates block promotion if critical issues are detected before staging or production reaches.

Feature flags decouple code deployment from feature release, enabling canary deployments and instant rollback without redeploying. They reduce risk by allowing gradual feature rollout, A/B testing, and quick disable without pipeline reruns.