What is Continuous Delivery (CD)?

What is Continuous Delivery (CD)?

Continuous Delivery is the software engineering practice in which every code change automatically progresses through build, test, and validation steps until it reaches a production-ready state — and can be deployed to production at any time with a single click or command. CD is the natural extension of Continuous Integration (CI): CI ensures every commit is built and tested; CD ensures every commit that passes is also packaged, deployed to staging, validated, and ready to ship.

The crucial distinction every team should understand: Continuous Delivery ≠ Continuous Deployment. Continuous Delivery means the change is ready to ship; humans decide when. Continuous Deployment means the change actually ships automatically on green CI. Most enterprise teams practice CD (release on demand); fewer practice Continuous Deployment (automated promotion to prod). Both abbreviate to "CD" causing constant confusion in interviews and architecture discussions.

The CD pipeline anatomy

A typical CD pipeline has these stages, each gating the next:

1. Source. Trigger on push to main / merge of PR. Pull source, compute commit metadata.
2. Build. Compile code, install dependencies, build container images. Cache aggressively (npm cache, Docker layer cache, Gradle cache).
3. Unit tests. Run in parallel; aim for under 5 minutes. Fail-fast on first broken test.
4. Static analysis. Linters, type checkers, security scanners (Snyk, Dependabot, SonarQube).
5. Integration tests. Spin up dependencies (databases, mock services), run integration suite. 5-15 minutes typical.
6. Artifact creation. Build container image, sign it, push to registry. Or build static binaries / packages.
7. Deploy to staging. Auto-deploy to a staging environment that mirrors prod.
8. Smoke tests / E2E. Critical-path validation against staging. Some teams run a load test here too.
9. Production gate. Manual approval (CD) or automatic promotion (Continuous Deployment).
10. Production deploy. Blue/green, canary, or rolling deployment. Monitor metrics post-deploy.
11. Post-deploy validation. Smoke tests on prod. Auto-rollback on regression.

The four deployment strategies CD enables

• Blue/green. Deploy new version ("green") alongside old ("blue"); switch traffic instantly. Easy rollback (switch back). Doubles infrastructure during transition.
• Canary. Deploy to small % of traffic first (1-5%); monitor; gradually increase. Catches regressions before full rollout. Industry default for high-traffic systems.
• Rolling. Replace instances one at a time. No traffic split logic needed; slower rollout. Default in Kubernetes and most cloud platform managed services.
• Feature flags / dark launching. Deploy code dark, enable per user/cohort via flag service. Decouples deploy from release. See feature flags.

What makes CD work in practice

Patterns that mature CD pipelines share:

• Trunk-based development. Short-lived branches (1-2 days max) merged to main. No long-lived feature branches that diverge for weeks.
• Comprehensive automated tests. If you can't trust your test suite, you can't trust CD. Aim for 80%+ critical-path coverage.
• Immutable artifacts. Same artifact deploys to staging and prod. No rebuilds between environments — too risky.
• Configuration externalized. Per-environment config in environment variables / config service, not baked into images.
• Database migration discipline. Migrations are forward-compatible; old code keeps working with new schema for at least one deploy cycle (expand-contract pattern).
• Observability. Metrics, logs, traces in production. Auto-rollback triggers on error rate / latency regression.
• Fast pipeline. Deploys take <15 minutes. Slow pipelines mean fewer, larger releases — exactly the failure mode CD is meant to prevent.

Common CD pipeline tools

• GitHub Actions — dominant for projects on GitHub. Marketplace ecosystem; .github/workflows YAML.
• GitLab CI/CD — first-class for GitLab. .gitlab-ci.yml; built-in container registry.
• CircleCI, Buildkite, Jenkins — third-party CI services. Jenkins is legacy but ubiquitous in enterprise.
• Argo CD, Flux — GitOps controllers for Kubernetes. Pull-based deploys synced from Git.
• Spinnaker, Harness, Octopus — full deployment-orchestration platforms. Multi-cloud, complex pipelines.
• AWS CodePipeline, Azure Pipelines, Google Cloud Build — cloud-provider native pipelines.

Common CD anti-patterns

• The "manual gate forever". CD pipeline ends at staging because nobody trusts production deploys. Either fix the trust problem (better tests, observability, rollback) or admit you don't have CD.
• Branch-based environments. Different code on staging vs. prod ("this branch deploys to staging"). Drift accumulates; staging passes but prod fails. Ship from main only.
• Deploys requiring out-of-band coordination. Someone has to update a config file in another repo; another team has to bounce a service. CD doesn't survive this.
• Catch-all integration tests in prod. Smoke tests should be cheap and fast. If your post-deploy validation takes 30 minutes, deploys queue up.
• No rollback drill. First time you exercise the rollback path is during a real outage. Practice rollbacks regularly.
• CI tests passing but not running on the deploy artifact. Easy to drift between what CI tests and what gets shipped. Build once, test the artifact, deploy the artifact — same bytes throughout.

FAQ: Continuous Delivery

What's the difference between CI, CD, and Continuous Deployment?

CI (Continuous Integration): every commit builds + tests. CD (Continuous Delivery): every commit also reaches a deployable state, ready to ship on demand. Continuous Deployment: every passing commit auto-ships to prod. CD is necessary for Continuous Deployment but not the same.

Do I need Kubernetes for CD?

No. CD works with VMs, containers, serverless, even FTP-deployed PHP. Kubernetes makes some patterns easier (rolling updates) but isn't required.

How long should a CD pipeline take?

Industry benchmarks (DORA, Accelerate): elite teams deploy in <1 hour from commit. High-performing teams: 1-24 hours. Pipelines >24 hours indicate problems with test infrastructure, dependencies, or organizational complexity.

Can CD work in regulated industries?

Yes — fintech, healthcare, government all run CD. The CD pipeline becomes the auditable trail (every change is built, tested, signed, deployed via reproducible steps with full logs). Often more auditable than manual deploy processes.

What about database changes?

The hardest part. Use expand-contract migrations (add new column → deploy code that writes to both → migrate old data → deploy code that reads new column → drop old column), feature flags, and tools like Flyway or Liquibase to version migrations alongside code.

How do I measure CD pipeline quality?

DORA's four key metrics: deployment frequency, lead time for changes, change failure rate, mean time to restore. Track these over time. Faster + safer = better CD.

What about microservices CD?

Each service has its own pipeline; deploys are independent. Coordinate breaking API changes via expand-contract or versioning. Avoid distributed monoliths where N services must deploy together.

How LoadFocus relates to CD pipelines

The most-skipped step in CD pipelines is performance validation. Functional tests pass; latency regresses 50% on prod traffic. LoadFocus API load testing integrates into CI/CD pipelines via API calls — fail the build if p95 latency exceeds your threshold. Synthetic monitoring validates Core Web Vitals stay healthy after every deploy, catching frontend regressions before users notice.