Continuous Delivery (CD) workflows define the automated sequence your software follows after successfully passing Continuous Integration (CI). Rather than merely building and testing, a CD workflow systematically prepares your application for release, ensuring that at any given moment, your codebase is in a deployable state with high confidence. It orchestrates a series of automated stages designed to move your validated artifact through various environments, progressively building trust and identifying issues early.
A typical CD workflow begins by taking the artifact (e.g., a Docker image, JAR, or compiled binary) produced during CI. This artifact is then automatically packaged and deployed to lower environments such as development, staging, or QA. In these environments, further automated tests like integration, end-to-end (E2E), and performance tests are executed. Crucially, the workflow incorporates gates—these can be automated checks (e.g., all E2E tests pass) or manual approvals (e.g., a QA team sign-off) that must be met before the artifact can advance to the next, more critical environment.
The essence of "delivery" in Continuous Delivery means your application is always release-ready. While deployments to non-production environments are fully automated, the final deployment to production often involves a deliberate, manual approval or trigger. This empowers business stakeholders to decide when to release a stable, fully tested version, without being constrained by technical readiness. By automating this entire journey, CD workflows dramatically reduce deployment risk, provide rapid feedback loops, and enable faster, more reliable software delivery.
Key Takeaways
- Automates the entire journey from a successful CI build to a production-ready application.
- Systematically deploys and tests the artifact across multiple environments (dev, staging, etc.).
- Incorporates automated and manual gates to ensure quality and control at each stage.
- The application is always in a release-ready state, with production deployment often a manual business decision.
- Significantly reduces deployment risk, speeds up feedback, and enables faster iterations.
Code Example
# Simplified CD Workflow Example (GitLab CI / GitHub Actions)
stages:
- build
- test
- deploy_dev
- deploy_staging
- manual_prod_approval
- deploy_prod
deploy_to_staging:
stage: deploy_staging
script:
- echo "Deploying to Staging..." # Assumes prior build/test
manual_approval_for_prod:
stage: manual_prod_approval
rules:
- if: $CI_COMMIT_BRANCH == "main"
when: manual # Requires a user click
needs: [deploy_to_staging] # Depends on staging deployment
deploy_to_production:
stage: deploy_prod
script:
- echo "Deploying to Production!"
needs: [manual_approval_for_prod] # Depends on manual approvalHow this code works
This pipeline code sets up a Continuous Delivery workflow, automating deployments to different environments while ensuring critical human oversight. Its primary job is to demonstrate a staged rollout from a staging environment to production, incorporating a necessary manual approval step before reaching live users.
The stages section defines the sequence of operations: build, test, deploy_dev, deploy_staging, manual_prod_approval, and deploy_prod. The deploy_to_staging job handles deployment to a testing environment. Crucially, the manual_approval_for_prod job acts as a gate; its rules ensure it's only active for changes on the main branch, and when: manual means a human must explicitly click to proceed. This job also uses needs: [deploy_to_staging], meaning staging must complete successfully before approval can even be sought. Finally, deploy_to_production deploys to the live environment, but its needs: [manual_approval_for_prod] line ensures it only runs after that manual gate has been passed. A subtle point is that a job with when: manual won't automatically fail if left untriggered; it will simply remain pending indefinitely, blocking subsequent stages until approved or manually canceled.