CI vs CD

CI and CD are not two names for the same thing. They are two distinct practices that operate on different parts of the software delivery pipeline, at different speeds, with different goals. Continuous Integration is about keeping code healthy — merging often, building fast, catching bugs while they are cheap. Continuous Delivery and Deployment are about keeping software shippable — packaging what CI verified, moving it through environments, and getting it in front of users. CI asks: "does this code work?" CD asks: "can this code ship?"

The reason this distinction matters is practical. Teams that conflate the two either build a CI system and call it "CI/CD" — then wonder why releases are still painful — or they set up a deployment pipeline without a solid CI foundation and end up automating the release of untested code. Getting both right requires understanding exactly what each practice is responsible for, and where the boundary between them sits.

Two Different Questions, Two Different Pipelines

Here is the clearest way to understand the split. When a developer pushes a commit, two questions need to be answered before that code can be in production. CI answers the first. CD answers the second. Neither can answer the other's question — and neither is complete without the other.

The Handoff: What Happens at the Boundary

The handoff from CI to CD is a specific, definable moment in the pipeline. It happens when a build passes CI and produces an artifact — a Docker image, a compiled binary, a packaged archive. That artifact is the baton being passed. CI created it. CI verified it. Now CD takes it and asks a harder question: not "does it work in isolation on a clean build machine" but "does it work in a real environment, against real dependencies, behaving the way a real user would experience it?"

This is why you should never rebuild the artifact at each environment — as warned in Lesson 5. The artifact is the proof of work. Rebuilding it breaks the chain of custody. What CD is doing is taking the exact thing CI blessed and subjecting it to increasingly realistic conditions until the team is confident enough to put it in front of real users.

Speed vs Depth: Why CI and CD Run at Different Tempos

One of the most practical differences between CI and CD is the speed at which they are expected to run — and why.

CI must be fast because it runs on every commit, and a slow CI pipeline is one that developers stop waiting for. The moment a developer decides to push another commit before the first build has finished, CI has lost. Ten minutes is the widely accepted upper limit — fast enough that a developer can make a coffee, come back, and still have the result fresh in their mind.

CD does not have the same constraint. It runs less frequently — only on merges to main — and its job is depth, not speed. Full end-to-end test suites against a production-like environment can legitimately take 20 to 40 minutes. That is acceptable because nobody is standing at their desk waiting for permission to continue working. CD runs in the background while the team moves forward. The output arrives when it arrives, and it is authoritative when it does.

This tempo difference is why mixing the two pipelines is a mistake. Teams that bolt their acceptance tests onto their CI pipeline create a 40-minute CI run that nobody waits for. Teams that run only fast unit tests in CD end up with a shallow delivery check that misses integration failures. Keep them separate. Let each one do its job at its own pace.

The Three Misconceptions That Cause Real Problems

Most CI/CD failure stories — teams that "adopted CI/CD" but still have painful releases, or teams that broke production repeatedly after automating their pipeline — trace back to one of three misconceptions about the CI/CD boundary. They are worth naming directly.

A Full Picture: CI and CD Working Together

When CI and CD are both working properly — with the right checks in each, running at the right speed, on the right triggers — the experience for a developer is almost invisible. They push code. Something happens automatically. Some time later, that code is live. The machinery is transparent. That invisibility is the goal.

Practice Questions

Answer in your own words — then check against the expected answer.

Lesson Quiz