What CI Actually Is. What CD Actually Is. And Why Most Engineers Confuse The Two.
Everyone says CI/CD. Almost nobody can cleanly define the two letters or draw the line between them. A definitions-first walkthrough: what CI is, what CD is, why there are actually two CDs, and where one ends and the other begins.
Nobody Can Say Where CI Ends And CD Begins
I was on the interview panel for a senior frontend role recently. Strong candidate, clean design round, solid coding. Near the end I asked what I thought was a warm-up question: "What does CI/CD stand for, and what is the difference between the two?"
The answer was: "CI/CD is the pipeline that runs your tests and deploys your code." That is not exactly wrong, but it is not really an answer. I pushed a little: "Okay, but what specifically is the difference between CI and CD?" Long pause. "One is the build, one is the deploy."
If I am being honest, that same fuzzy answer is one I would have given a couple of years into my own career. The two acronyms have been squashed together into a single blob that means "the yellow tick on my PR", and the actual definitions - which are precise, historic, and quite different - have been quietly lost.
This article is one thing: the definitions, laid out clearly, and the line between them drawn where it actually sits. No pipeline YAML, no vendor comparisons, no war stories. Just the words and what they mean.
"CI and CD are two distinct engineering disciplines. If you cannot say which one you are talking about, you probably do not do the second one at all."
CI/CD Is Not Two Terms. It Is Three.
The first thing that trips people up is that there are three distinct terms folded into the abbreviation, not two:
- CI - Continuous Integration. The practice of merging every developer's in-progress work into a shared main branch several times a day, with every merge automatically built and tested to prove the shared branch still works.
- CD - Continuous Delivery. The practice of making sure every commit that passes CI produces a build artefact that is ready to go to production, on demand. The release itself is a deliberate human action - one button, one approval - but the artefact is always shippable.
- CD - Continuous Deployment. Same as Continuous Delivery, except the button is removed. If the commit passes CI, it goes to production automatically. No human in the loop.
Both of the last two are called CD, and this is the single biggest source of confusion in the whole vocabulary. When someone says "we do CD", the correct follow-up question is: "delivery or deployment?" One is a discipline. The other is a specific choice on top of that discipline.
Continuous Integration - The Definition
Continuous Integration is a software engineering practice where every developer on a team integrates their work into a shared main branch frequently - at least once a day, ideally more - and every integration is verified by an automated build and test suite.
Two words in that definition do the heavy lifting: integrates and frequently.
- "Integrates" means merged into the shared main branch. Not pushed to a personal feature branch. Not opened as a draft PR. Actually merged into the trunk that everyone else is also building on.
- "Frequently" means at least once a day per engineer. Not once a sprint. Not "when the feature is done". If your branches routinely live longer than a day, you have adopted the tooling of CI without adopting the practice.
The automated build and test suite is not what CI is. It is what makes CI safe. Without automated verification, merging half-finished changes daily would break the main branch constantly. With it, small, well-tested changes can flow through the trunk on a rhythm that keeps everyone's local state aligned with everyone else's.
This is why "we have CI" is a weaker claim than most teams realise. Running tests on a PR is table stakes. Merging every developer's work every day into a shared main branch - that is the practice. Everything else is tooling in support of it.
"The 'continuous' in CI is not about the pipeline. It is about the humans - about how often they merge their work into each other's."
Continuous Delivery - The Definition
Continuous Delivery is a software engineering practice where every commit that passes CI produces a build artefact that is ready to be released to production, at any moment, without any additional engineering work.
The important word here is ready. Continuous Delivery does not mean "we release often". It means "we could release right now". Whether we choose to release is a separate decision. The engineering promise is that the choice is always available.
What "ready" means concretely:
- Every merged commit produces an artefact that could go to production as-is. No re-building, no last-minute config edits, no cherry-picks.
- No feature sitting in main is half-shipped. Anything incomplete is behind a flag, off by default. Merging into main and being exposed to users are two different events.
- Environment differences are runtime configuration, not build-time forks. The exact artefact that runs in staging is the exact artefact that runs in production.
- Nothing about the release requires a human running a manual step, remembering to warm a cache, or coordinating a handoff between teams.
- Rollback is as fast and as one-click as release. If release is a five-minute job, rollback is not a forty-minute job.
Every one of those is an engineering discipline. Feature flags, backward-compatible migrations, config isolation, artefact signing. Continuous Delivery is not a pipeline setting. It is what a team commits to when it says "every green commit is releasable, right now".
Pick a random green commit from main in the last month. Can that exact commit be released to production right now, without cherry-picking, without a hotfix branch, without a config change? If the answer is anything other than a clean yes, the team does not have Continuous Delivery. They have hopeful releasability.
Continuous Deployment - The Definition
Continuous Deployment is Continuous Delivery with the human button removed. Every commit that passes CI is automatically released to production. There is no manual approval, no scheduled release window, no gatekeeper.
The important thing about this definition is what it does not change. It does not lower the engineering bar - if anything, it raises it. Continuous Delivery says "the artefact is ready, humans decide when to release". Continuous Deployment says "the artefact is ready, and we trust the pipeline to release it without human review".
That trust is not free. Continuous Deployment sensibly requires:
- Real observability - within a minute or two of a deploy, the team can answer "is this deploy healthy" from metrics, not from feelings.
- Progressive rollout - the new version is exposed to a small slice of traffic first, and only expanded if the health signal is clean.
- Automated rollback - if the health signal is not clean, the system rolls back without waiting for someone to click a button.
- Cultural buy-in that rollbacks are routine, not failures. If a rollback is seen as a career hit, engineers will suppress them, and Continuous Deployment turns dangerous.
Notice that none of these are strictly required for Continuous Delivery. Delivery is a lower bar because a human is the gate. Deployment automates the gate away and therefore has to reproduce the gate's judgement in software.
Where CI Ends And CD Begins
Now that both sides have definitions, the boundary is easier to draw than the fog around "CI/CD" suggests. The line is not "before vs after the tests run". It is not "PR pipeline vs deploy pipeline". It sits at a very specific point.
CI ends the moment a commit is merged into main and its build artefact has been produced and verified. That artefact - a compiled binary, a signed bundle, a container image, whatever your platform is - is CI's output.
CD begins the moment that artefact exists and asks: what do we do with it? Continuous Delivery keeps that artefact permanently releasable and lets a human choose when to release it. Continuous Deployment releases it immediately.
Everything before the artefact is CI. Everything after it is CD. That is the whole boundary.
"The artefact is the border between CI and CD. Before the artefact, you are integrating. After it, you are delivering."
This has one interesting consequence. If your CI pipeline stops at "the tests passed" and does not produce a versioned, signed, addressable artefact, you have no output to hand over to CD. You have not built the border stone. This is why so many teams that claim CI/CD are actually only doing CI - their CI never produced the thing that CD is defined to operate on.
CI vs CD, Side By Side
If you take one thing from this article, this is the shape:
| Dimension | CI - Continuous Integration | CD - Continuous Delivery / Deployment |
|---|---|---|
| What it does | Merges every developer's in-progress work into a shared main branch, verified by an automated build and test suite. | Turns every merged commit into a production-ready artefact and, in the deployment variant, releases it automatically. |
| Primary output | A stable, always-green main branch and a signed build artefact. | A production release - or the standing ability to trigger one at any moment. |
| Runs against | Every push to a branch under review, and every merge to main. | Every artefact produced by CI on main. |
| Human involvement | Engineers merge frequently. The pipeline runs itself. | Delivery: a human presses release. Deployment: no human, the pipeline releases. |
| Failure mode | Main branch is broken and the team is blocked. | A bad release reaches users; requires rollback and (for deployment) automated safety nets. |
| Prerequisite | Trunk-based development. Fast, trustworthy tests. Small, frequent commits. | A working CI. Feature flags. Backward-compatible migrations. Rollback capability. |
| Question it answers | "Does the shared codebase still work after this change?" | "Is this change ready for users - and (deployment only) do we send it to them right now?" |
Read that table again. Every row has a different answer for CI and for CD, and that is the point - they are not two halves of one thing, they are two things that happen to be adjacent in the pipeline.
Common Misconceptions About CI
Once the definition is clear, several widely-held beliefs about CI start to look wrong.
"CI is running tests on my PR."
Running tests on a PR is a mechanism CI depends on. It is not what CI is. A team can run tests on every PR and still not be doing Continuous Integration - if the average branch lives two weeks before merging, the "continuous" part is missing.
"CI catches bugs before they reach production."
CI catches integration bugs before they reach main. That is a much narrower claim, and it is the correct one. Whether the code reaches production or not is CD's problem, not CI's.
"CI requires GitHub Actions / Buildkite / CircleCI."
CI requires a build server that can run reliably on every commit. The vendor is a choice. Teams did CI for years with Jenkins, with custom shell scripts, with cron jobs pulling from svn. The tooling has changed. The practice has not.
"CI is the same as automated testing."
Automated testing is what makes CI cheap. But you can have automated tests without CI (they just run on your machine, or once a night, disconnected from merges) and, in theory, you can have CI with no tests at all (just build verification). The tests are the fuel. CI is the engine.
Common Misconceptions About CD
The same clean-up is worth doing for CD, because there is arguably more myth around it.
"CD means we deploy on every commit."
Only Continuous Deployment means that. Continuous Delivery, the other CD, means we could deploy on every commit. Many mature teams practise the delivery flavour deliberately because their business does not want automatic releases.
"CD is a pipeline stage."
CD is a discipline. The pipeline stage that runs a deploy is a mechanism CD relies on, but the discipline is about the promise the team makes: every green commit is production-ready. Without that promise, all the deploy automation in the world is just a fast way to ship broken code.
"CD requires Kubernetes / a service mesh / a fancy platform."
CD requires versioned artefacts, safe rollout, and reliable rollback. That can be a Kubernetes deployment or it can be a CDN invalidation for a static bundle. The mechanics vary; the discipline does not.
"CD is riskier than manual releases."
Sometimes. But manual releases have their own failure mode - they are rare, high-stakes events where a lot of changes ship together and a bug is hard to attribute. CD, done well, means each release is small and traceable to one change, which is often safer than a monthly manual release of thirty changes. The risk depends on how the discipline is implemented, not on the automation itself.
The Whole Article In Two Sentences
If you want to walk away with the shortest correct version of this article, it is these two sentences.
Continuous Integration is the practice of merging every developer's work into a shared main branch several times a day, verified by an automated build and test suite that produces a shippable artefact.
Continuous Delivery is the practice of keeping that artefact permanently ready to release to production at the press of a button; Continuous Deployment removes the button and releases every green artefact automatically.
Everything else in this article is elaboration on those two sentences. The next time you hear "we do CI/CD", pin down exactly which of the three practices the speaker means. You will almost always find they mean one of them, sometimes two, and very rarely all three - and the conversation gets a lot sharper the moment you know which.
"CI is a discipline about how humans work with each other. CD is a discipline about how code moves through a system. Squashing them into one acronym hides both."
Related essays
- CI/CD · Build Systems
Your CI Cache Is a Second Package Manager. Treat It Like One.
A CI cache can cut minutes from a build, or quietly make your release process non-reproducible. The difference is whether you treat it as disposable acceleration or hidden infrastructure.
- CI/CD · DevOps
Buildkite vs GitHub Actions: A Web Infrastructure Engineer's Honest Take
I have spent the better part of two years running both of these in production across teams of different shapes and sizes. Here is everything I wish someone had told me before I started forming opinions.
- CI/CD · DevOps
The Death of the Traditional CI/CD Pipeline
How AI-assisted deployments, platform engineering, and a new generation of tooling are dismantling the pipeline model we've relied on for a decade, and what actually comes next.