“CI/CD” is often used as a single blurred term, but it actually describes three distinct practices, and the distinction between the second and third — continuous delivery and continuous deployment — is one that’s worth being precise about, because it changes what a “green pipeline” actually promises.

Continuous integration: merge often, test automatically

Continuous integration (CI) is the practice of merging code changes into a shared branch frequently — multiple times a day, in mature implementations — with each merge automatically triggering a build and test run. Martin Fowler’s original description of continuous integration frames the goal directly: catch integration problems as early as possible, when a small, recent change is easy to diagnose, rather than discovering conflicts after days or weeks of parallel, undetected divergence.

The practice depends on two things working together: a test suite fast and reliable enough to run on every merge, and a team discipline of actually merging frequently rather than working in long-lived branches. Without both, “we use CI” often just means “we have a build server,” without the actual continuous-integration behavior the term describes.

Continuous delivery: always deployable, deployment still a choice

Continuous delivery (CD) extends CI: every change that passes the automated pipeline is automatically built, tested, and prepared for release — often deployed to a staging environment — such that it could be released to production at any time. The distinguishing feature is that the actual production release remains a deliberate, usually manual, decision. Martin Fowler’s description of continuous delivery and the canonical continuousdelivery.com reference both frame it this way: the software is always in a releasable state, but a human still decides when to release it.

Continuous deployment: the manual gate removed

Continuous deployment goes one step further and removes that manual gate: every change that passes the automated pipeline deploys straight to production, with no human approval step. This is a materially bigger commitment than continuous delivery — it means your automated tests and pipeline checks are the only thing standing between a code change and production traffic, which raises the bar for how comprehensive and trustworthy that automated pipeline needs to be.

Confusing these two is a common, and consequential, mistake: a team that describes itself as doing “continuous deployment” while actually requiring manual sign-off is doing continuous delivery, and the difference matters when reasoning about incident risk and change failure rate.

Why this distinction affects reliability practice

Whichever model a team uses, the deployment mechanics matter for minimizing risk when a release does go out — techniques like gradually shifting traffic to a new version rather than switching all at once. We cover two of the most common patterns for that in Blue-Green and Canary Deployments. And because a pipeline is only as trustworthy as the infrastructure it deploys onto, consistent, version-controlled infrastructure — covered in Infrastructure as Code: How Tools Like Terraform Actually Work — is a practical prerequisite for CD working reliably, not a separate concern.

What good CI/CD depends on in practice

Beyond the pipeline configuration itself, a handful of practical factors determine whether CI/CD actually delivers on its promise:

  • Test suite quality — a fast, comprehensive, reliable test suite is what CI’s early-warning property actually depends on; a slow or flaky suite undermines the entire premise.
  • Small, frequent changes — CI’s benefits scale with how small and frequent merges are; large, infrequent merges reintroduce the integration risk CI exists to prevent.
  • Observable pipelines and deployments — knowing quickly whether a deployment is healthy is what makes continuous deployment’s reduced manual oversight viable at all, a topic covered in What Is Observability?.

Vendor documentation from major CI/CD platforms describes the same underlying model in slightly different terms — see, for example, GitHub’s overview of GitHub Actions, AWS’s overview of continuous delivery, and Google Cloud’s continuous delivery guidance.

Key takeaway

Continuous integration, continuous delivery, and continuous deployment are three distinct practices with a shared foundation, not synonyms for “automated pipeline.” The practical difference that matters most is whether a human still approves the final production release (continuous delivery) or the pipeline does it unattended (continuous deployment) — and that distinction should shape how much you invest in automated testing and observability before removing the manual gate.

This article explains general CI/CD concepts; specific tools and platform features change over time. See our disclaimer and check current vendor documentation before adopting a specific tool.