CI/CD is a pipeline — an automated script that runs build, test, and deploy steps. Continuous Delivery is a discipline that produces shippable trunk on every commit. The two are not the same. Most teams have the first and assume they have the second, which is why their lead times are measured in weeks instead of hours.
Ask any engineering team whether they "do CI/CD" and the answer is yes. They have a pipeline. It runs on every commit. It builds, runs tests, and deploys to some environment.
Then ask whether they could push any commit on trunk to production right now, with no manual steps, no coordination call, and no approval ticket. The room goes quiet.
That gap is the difference between a CI/CD pipeline and Continuous Delivery. The industry has spent fifteen years conflating the two — which is why DORA's 2024 report watched the high-performing cluster shrink and the low-performing cluster grow, and 2025 had to retire the old Elite/High/Medium/Low tiers in favor of seven team archetypes that mostly describe different ways to be stuck.
"CI/CD" Doesn't Mean What You Think
Three terms get jumbled together every time someone says "we do CI/CD." Pulling them apart matters because each one describes a different thing.
Continuous Integration is a practice. Every developer integrates their work to trunk at least once per day, and every integration is verified by an automated build and test run. Long-lived feature branches are incompatible with CI by definition.
Continuous Delivery is a discipline. The team works in such a way that the software is always in a deployable state — every commit on trunk is a release candidate that could go to production at any moment. The decision to release becomes a business choice, not an engineering scramble.
Continuous Deployment is a deployment policy on top of CD. Every commit that passes the pipeline automatically goes to production with no human intervention.
A "CI/CD pipeline" is a tool. It is the automation script that runs in your CI server. It can run inside a CI process, inside a CD discipline, inside neither, or inside both.
Most teams have the pipeline. Most teams do not have the practice. The pipeline runs on a Friday afternoon against a release branch that has been accumulating six weeks of feature work. It executes flawlessly. It is automating a non-CD process. The team feels modern because the script is green.
Figure 1: A CI/CD pipeline is a single automated script. Continuous Delivery is a system of practices that produces a shippable trunk on every commit. The pipeline can exist without the practice — and usually does.
Why the Pipeline Isn't the Practice
The pipeline is necessary. It is not sufficient. Here is what we see when we audit teams who say they "do CI/CD."
Long-lived feature branches. Work sits on a branch for two weeks. The pipeline runs on the branch and stays green. Then the merge to main is a 1,400-line surprise that breaks three other in-flight branches. There is no continuous integration happening. There is a pipeline running on islands of code.
Batched releases. The team merges to main throughout the sprint, but production deployment happens every other Thursday during a one-hour release window with everyone on a Slack call. The pipeline ends at staging. The path to production is a release manager.
Manual QA gates. The pipeline builds and tests, then a separate QA team picks up the artifact, runs a regression suite, files tickets, and signs off three days later. Deployment cannot happen without that signoff. The pipeline is fast. The release process is slow.
Hardening sprints. Every quarter, feature work pauses for two weeks of "stabilization" — fixing the defects that accumulated during the previous quarter. A team that needs hardening sprints does not have CD. It has scheduled debt repayment.
Change advisory boards. Production deployment requires a CAB ticket, an external approval, a rollback plan document, and a maintenance window. The pipeline produces the artifact. The CAB decides when it ships.
These are five different ways to have a pipeline without having Continuous Delivery. None of them are unusual. All of them are the default in organizations that bought into CI/CD tooling without adopting CD practices. As beyond.minimumcd.org puts it: "infrequent deployment is self-reinforcing." Each batched release teaches the team that releases are scary. Each scary release argues for more gates. The pipeline is fine. The system around it is the problem.
The Practices That Actually Matter
Continuous Delivery is not a feature you turn on. It is a set of practices that, when running together, make every commit on trunk a release candidate. Skip any of them and the pipeline is automating a broken process.
Figure 2: The CD practice stack. Each layer is prerequisite to the next. Skipping the foundations and starting at the top is what produces a CI/CD pipeline running inside a non-CD process.
Trunk-based development. Every developer integrates to trunk at least daily. No long-lived branches. No feature branches that age. Where short-lived branches exist, they live for hours, not days. This single practice eliminates more delivery problems than any other — most pipeline pain is downstream of branch age.
Small batch sizes. Work is decomposed so that every commit is independently shippable. This is not a developer instinct, it is a planning discipline. Stories that don't look independently shippable in a few days get split during planning, not during sprint review.
Effective tests at the right pyramid level. Unit tests run in seconds. Component and contract tests run in minutes. Acceptance tests verify user-facing behavior in a production-like environment. The whole suite is fast enough that developers do not avoid running it. And the suite is effective, not just present — covered in detail in 88% of Your Tests Are Decorative and The Mutation Testing Playbook.
Build once, deploy many. The pipeline produces an immutable artifact. That same artifact is promoted across environments — dev, staging, production — with configuration injected at deploy time. Rebuilding for production is rebuilding the risk surface. If the artifact in staging is not byte-for-byte the artifact that reaches production, staging is theater.
Production-like environments. Test environments mirror production in topology, configuration, data shape, and dependency versions. "Works on staging, breaks in production" is not a deployment problem. It is an environment parity problem.
Single path to production. Every change — feature, fix, configuration, infrastructure — flows through the same pipeline. There is no hotfix backdoor. There is no ops-team-only path. The pipeline is the only way code reaches production, which means the pipeline is the only place quality gates need to live.
Stop the line on red. When trunk is red, fixing it is the team's top priority. Not "next sprint." Not "after this story." Now. A team that ignores a red trunk is a team teaching itself that the pipeline is decorative.
Decouple deployment from release. Feature flags, dark launches, and progressive rollout separate the question "is this code in production?" from "is this feature visible to users?" Deployment becomes a low-risk routine. Release becomes a product decision.
These practices are not a maturity model. They are interlocking — skipping one undermines the others. Trunk-based development without a fast test suite is chaos. A fast test suite without small batches gets bypassed because the changes it has to verify are too big. Immutable artifacts without environment parity create false confidence. The system only works as a system.
How to Tell If You Have CD
The diagnostic is one question: could you deploy any commit currently on trunk to production right now, with no manual steps and no coordination?
The honest answer falls into one of three buckets:
- Yes, every commit, automatically. That is continuous deployment running on top of CD.
- Yes, every commit, on demand. That is Continuous Delivery. Deployment is a business decision, not an engineering scramble.
- Only after a release window, signoff, batched cut, or coordination call. That is a CI/CD pipeline running inside a non-CD process.
The lagging metric is lead time for changes. The fastest teams measure it in hours. Most teams measure it in weeks or longer. The gap between those two numbers is almost never about pipeline speed — it is about everything described above.
For teams in the third bucket, the path forward is not buying a better pipeline tool. It is sequencing the foundations: integrate to trunk daily, decompose work into small batches, build a test suite that catches real defects in under ten minutes, then a single automated path to production. The pipeline you already own gets meaningfully more useful the moment those practices are real.
The Bottom Line
A CI/CD pipeline is a tool. Continuous Delivery is a discipline. The pipeline runs on whatever process you point it at — including a process that batches releases, gates on manual QA, and freezes for two weeks each quarter. Buying tools that say "CI/CD" on the box does not give you CD any more than buying a treadmill makes you a runner.
The practices are not exotic. They are decades old, well-documented, and freely available at beyond.minimumcd.org. What stops most teams is not the practices themselves but the assumption that the pipeline already covers them. It does not. The pipeline is the easy part. The practices are the work.
