CI
CircleCI Deployment Pipelines
Deployment workflows, approval gates, environment promotion, and rollback strategies
Details
Language / Topic
CircleCICategory
Deployment
Rules
balanced
- Use workflow approval jobs (type: approval) to gate production deployments with manual human review
- Implement environment promotion: build once, deploy to staging, approve, then promote the same artifact to production
- Use branch filters to control deployment targets: main deploys to production, develop deploys to staging
- Separate deploy credentials using contexts: staging-deploy and production-deploy with different access restrictions
- Use OIDC tokens for cloud deployments to avoid storing long-lived credentials in CircleCI
- Use approval jobs for production deployment gates: `type: approval` pauses the workflow until a team member approves in the CircleCI UI
- Implement environment promotion: build artifacts in the build job, deploy to staging, run smoke tests, require approval, then deploy the same artifacts to production
- Use branch filters on deploy jobs: `filters: branches: only: [main]` for production, `only: [develop]` for staging — prevent accidental deploys from feature branches
- Scope deploy credentials to contexts: staging-deploy-context restricted to develop branch, production-deploy-context restricted to main with security group access
- Use OIDC tokens ($CIRCLE_OIDC_TOKEN) to assume cloud provider roles during deployment — no static AWS keys or GCP service account JSON stored in CircleCI
- Use workspaces to pass build artifacts through the promotion pipeline: build -> persist_to_workspace -> attach_workspace in deploy jobs
- Add smoke test or health check jobs after deployment: verify the deployed service is healthy before marking the pipeline as successful
- Use scheduled pipelines for recurring deployments or nightly releases instead of manual triggers
- Implement rollback by rerunning a previous successful pipeline or deploying the last known good artifact from workspace/registry
- Tag successful production deployments in your container registry or artifact store for easy rollback targeting
- Use pipeline parameters for deployment flexibility: `parameters: target-env: { type: enum, enum: [staging, production], default: staging }`