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

A solid way to set this up is to choose a CD tool that supports:

• Environment promotion: dev → test → staging → prod
• Manual approvals / gates before production
• Audit trail of who approved what and when
• Git-based or pipeline-as-code definitions so it’s reproducible

Common options:

• GitHub Actions with environments and required reviewers
• GitLab CI/CD with protected environments
• Azure DevOps Pipelines with approvals and gates
• Argo CD / Flux for GitOps-style promotion
• Jenkins with approval stages/plugins, though more hands-on to manage

Recommended setup pattern

1) Define environments clearly

Create separate deploy targets such as:

• dev
• qa
• staging
• prod

Each environment should have:

• its own credentials/secrets
• deployment config values
• access controls
• rollback strategy

2) Use artifact promotion, not rebuilds

Build once, then promote the same artifact through environments.

Example flow:

1. CI builds app artifact/container image
2. Deploy artifact to dev
3. Run automated tests
4. Promote same artifact to staging
5. Run integration/smoke tests
6. Require approval
7. Deploy same artifact to prod

This avoids “works in staging, different build in prod” problems.

3) Add approval gates for production

Your CD tool should pause before prod and require one or more of:

• manual approval from an authorized user/group
• change ticket reference
• successful checks from test suites
• security scan thresholds

4) Separate deployment logic from application code

Store pipeline config in source control:

• deployment manifests
• Helm charts
• Kustomize overlays
• pipeline YAML / workflow files

This makes promotion repeatable and reviewable.

5) Use environment-specific configuration

Keep environment differences outside the app binary:

• config maps / env vars
• secret managers
• per-environment values files

Avoid hardcoding environment settings.

6) Protect production access

Use:

• branch protections
• environment protection rules
• least-privilege service accounts
• separate prod credentials
• audit logging

Example with GitHub Actions

GitHub Actions supports environments with required reviewers.

High-level setup:

1. Create environments: dev, staging, prod
2. Add secrets per environment
3. Enable required reviewers on prod
4. Make the workflow deploy sequentially

Example conceptually:

• push to main triggers build
• deploy to dev automatically
• on success, deploy to staging
• on success, job pauses for prod approval
• after approval, deploy prod

Example with GitOps

If you want strong control and traceability:

• Use Argo CD
• Application manifests live in Git
• Promotion = changing image tag or manifest in a higher environment repo/folder
• Production deployment happens only when the prod Git path is updated and approved

This is especially good for Kubernetes.

Key implementation checklist

• Build once, promote same artifact
• Separate environments and credentials
• Automated tests at each stage
• Manual approval before production
• Audit logs and notifications
• Rollback procedure
• Git-controlled pipeline/deployment config

Which tool should you choose?

• Simple app + GitHub: GitHub Actions
• Enterprise approvals/compliance: Azure DevOps or GitLab
• Kubernetes/GitOps: Argo CD
• Legacy/on-prem flexibility: Jenkins

If you tell me your stack (GitHub/GitLab/Azure, Kubernetes or not, cloud provider, and app type), I can suggest a concrete setup and sample pipeline.