DevOps practices comparison
CI vs CD
Three acronyms that are often run together but mean distinct things. Understanding where CI ends and CD begins — and the difference between Continuous Delivery and Continuous Deployment — is essential vocabulary for any engineer working in a modern team.
TL;DR
- CI (Continuous Integration) — developers merge code to a shared branch frequently (at least daily). Each merge triggers an automated build and test run to detect integration problems early.
- CD (Continuous Delivery) — every passing CI build produces a release-ready artifact. Deploying to production requires a human approval step.
- CD (Continuous Deployment) — every passing build is automatically deployed to production. No human gate. Requires very high confidence in automated tests.
Side-by-side comparison
| Aspect | CI | Continuous Delivery | Continuous Deployment |
|---|---|---|---|
| Automation level | Build + test on every commit | Build + test + staging deploy automated | Build + test + production deploy automated |
| Human gate | None required by definition | Yes — production deploy requires approval | No — production deploy is fully automatic |
| Release frequency | Artifact per commit; release is manual | Release when the team decides | Multiple releases per day |
| Rollback | Revert the commit, re-run pipeline | Re-deploy a previous artifact | Automated rollback on failed health checks |
| Test confidence required | Moderate — catches regressions | High — tests are the quality gate | Very high — tests are the only gate before production |
| Typical tooling | GitHub Actions, Jenkins, CircleCI | Same + ArgoCD, Spinnaker | Same + feature flags, canary deployments |
What CI gives you
- Fast feedback on broken builds. A developer knows within minutes if their change broke a test, rather than discovering it days later during a manual QA cycle.
- Smaller, safer merges. Frequent integration prevents long-lived branches that diverge dramatically and cause painful merge conflicts.
- Shared visibility. A green or red build status on the main branch is visible to the whole team — no surprises at release time.
What CD adds
- Deployment confidence. Every artifact that exits the pipeline is proven to build, pass tests, and deploy successfully to a staging environment.
- Reduced release risk. Small, frequent releases are easier to debug and roll back than large quarterly deployments.
- Faster time to market. Features reach users days or hours after merging, not after a monthly release cycle.
- Continuous Deployment specifically removes release ceremonies entirely — engineers merge and the feature is live. Requires feature flags for gradual rollout and instant rollback capability.
English phrases engineers use
CI conversations
- "The CI pipeline is red — who broke main?"
- "The build broke on main; I'm reverting now."
- "All checks must be green before merging a PR."
- "We run unit tests and a linting step on every push."
- "The pipeline takes 8 minutes end to end — we need to parallelise."
CD conversations
- "We auto-deploy to staging on every merge to main."
- "Promotion to production requires approval from a team lead."
- "We're fully on continuous deployment — merging is releasing."
- "The canary is at 10% — error rate looks stable, promoting."
- "We use feature flags so we can deploy without releasing."
Key vocabulary
- Pipeline — the automated sequence of steps (build, test, deploy) run on every code change.
- Artifact — the deployable output of a build: a Docker image, JAR file, or compiled binary.
- Green / red build — all tests passing vs. at least one step failing.
- Staging environment — a production-like environment where code is deployed and tested before going live.
- Promotion — moving an artifact from one environment (staging) to the next (production).
- Feature flag — a runtime toggle that enables or disables a feature without redeploying code.
- Canary deployment — routing a small fraction of traffic to a new version to validate it before full rollout.
Quick decision tree
- We want fast feedback on every commit → CI (start here)
- We want every passing build to be release-ready → Continuous Delivery
- We want automatic production releases with no human gate → Continuous Deployment
- Regulatory approval required before production → Continuous Delivery (with approval gate)
- We release daily and trust our test suite → Continuous Deployment
Frequently asked questions
Is CD the same as continuous deployment?
CD stands for two related but distinct practices. Continuous Delivery means every successful build produces a release-ready artifact — but a human must approve the final push to production. Continuous Deployment goes one step further: every passing build is automatically deployed to production with no human gate. Most teams start with Continuous Delivery before trusting fully automated Continuous Deployment.
What triggers a CI pipeline?
Most commonly a push or pull request to a branch in the version control system. Pipelines can also be triggered on a schedule (nightly builds), by an external event (webhook from a dependency update), or manually by a developer. The trigger is configured in the pipeline definition file — for example, the "on" block in a GitHub Actions workflow.
Does CI require automated tests?
Technically no, but without tests CI provides far less value. The whole point of CI is to get fast, reliable feedback on whether a change broke anything. A pipeline that only builds and lints will catch some errors but misses logic regressions. Adding unit tests, integration tests, and at least a smoke test of the running service is what makes CI genuinely protective.
What is a deployment pipeline?
A deployment pipeline is the full automated path from code commit to production: it typically includes build → unit tests → integration tests → artifact creation → deploy to staging → smoke tests → approval gate (for CD) → deploy to production. The pipeline makes every step visible and auditable.
How do you handle a broken build on main?
The standard practice is to fix forward immediately — anyone who broke main is responsible for either fixing it or reverting the commit within minutes. Many teams enforce a "stop the line" rule: no new merges to main until the build is green. Some pipelines auto-revert a commit that causes a test failure on main.
What is a canary deployment?
A canary deployment routes a small percentage of production traffic (say 1–5%) to the new version while the rest goes to the old version. If error rates and latency look good after a monitoring window, the rollout is expanded. This is a common CD strategy for reducing the blast radius of a bad release.