How do I set up a continuous delivery tool for multi-environment promotion and production approvals?

A good way to set this up is to use a CD tool that supports pipelines with environments/stages, promotion between them, and manual gates/approvals. Common choices are Argo CD + Argo Rollouts, Spinnaker, Harness, GitHub Actions/GitLab CI with environment protections, or Azure DevOps.

Here’s a practical setup pattern that works well for multi-environment promotion and production approvals:

---

1) Define your environments

Typical progression:

• Dev – automatic deploy on merge
• Test/QA – automatic deploy after dev passes
• Staging/Pre-prod – promotion after validation
• Production – requires manual approval

Use the same deployment artifact across all environments to keep promotion consistent.

---

2) Make promotion artifact-based, not rebuild-based

Best practice:

• Build once
• Store the artifact/image in a registry
• Promote the same immutable version through environments

Example:

• Build Docker image myapp:1.4.7
• Deploy that exact image to dev, staging, then prod

This avoids “it worked in staging but prod got a different build.”

---

3) Separate deployment config from code

Use environment-specific config, such as:

• Helm values files
• Kustomize overlays
• Parameterized pipeline variables
• Config repositories

Example structure:

• values-dev.yaml
• values-staging.yaml
• values-prod.yaml

Keep secrets in a secrets manager, not in the repo.

---

4) Configure environment promotion in the pipeline

A common pipeline flow:

1. Build
2. Unit tests
3. Publish artifact
4. Deploy to Dev
5. Integration/smoke tests
6. Promote to QA/Staging
7. Run regression tests
8. Manual approval
9. Deploy to Production

Promotion can be:

• Automatic between lower environments
• Manual gated for production
• Approval by role/group such as QA lead, product owner, or release manager

---

5) Add approval gates for production

Use one of these mechanisms depending on your tool:

• Manual approval step
• Environment protection rules
• Required reviewers
• Change management integration
• CAB approval workflow
• Policy checks before deployment

Recommended approval conditions:

• Tests passed
• Security scan passed
• No open deployment blockers
• Release notes attached
• Change window valid, if applicable

---

6) Use deployment strategies for safer production releases

For production, consider:

• Blue/green
• Canary
• Rolling
• Feature flags

These reduce risk and let you verify the release before full rollout.

---

7) Add observability and rollback

Your CD tool should integrate with:

• Logs
• Metrics
• Traces
• Health checks
• Automated rollback on failed health checks

Good pipeline logic:

• Deploy
• Wait for health
• Run smoke tests
• If unhealthy, rollback automatically
• Notify the team

---

8) Enforce environment permissions

Control who can:

• Trigger deployments
• Approve production
• Edit pipeline definitions
• Change configs

Use RBAC and audit logs.

---

9) Example implementation patterns

Option A: GitHub Actions

Use:

• Environments: dev, staging, production
• Required reviewers on production
• Secrets per environment
• Deployment jobs with approvals

Option B: Argo CD

Use:

• GitOps for environment promotion
• Separate manifests per environment
• Argo CD sync to dev/staging
• Manual sync or approval for prod
• Argo Rollouts for canary/blue-green

Option C: Spinnaker/Harness

Use:

• Pipeline stages per environment
• Automated verification stages
• Manual judgment stage before prod
• Managed rollbacks and strategy support

---

10) A simple recommended setup

If you want a straightforward, modern pattern:

• Git repo for app + deployment manifests
• CI builds and tests
• Artifact registry stores immutable image
• GitOps CD tool like Argo CD deploys to environments
• Protected production environment with manual approval
• Smoke tests and monitoring after each deploy
• Rollback on failure

---

Example flow

Commit -> Build/Test -> Push Image -> Deploy Dev
       -> Smoke Tests -> Promote Staging
       -> Regression Tests -> Manual Approval
       -> Deploy Production -> Monitoring -> Rollback if needed

---

Key design choices

If you’re deciding how to implement it, ask:

• Do I want GitOps or pipeline-driven CD?
• Do I need approval workflows with audit trails?
• Do I want automated canary/blue-green?
• Do I need multi-tenant or multi-cluster support?
• Which environments must be manual gated?

---

If you want, I can give you:

1. a tool recommendation based on your stack,
2. a sample pipeline YAML, or
3. a reference architecture for Kubernetes, AWS, Azure, or GitHub/GitLab.