You're reading "CI/CD Is Not What You Think", written on January 27, 2026.
CI/CD Is Not What You Think
CI/CD is everywhere: conference talks, vendor decks, job descriptions. And yet most teams using the term are describing a build server with aspirations. Running tests on pull requests is good practice. Having a deployment pipeline is useful. Neither, on their own, is CI/CD.
CI/CD, in the sense that actually changes how teams deliver software, is a structural response to a scaling problem: how to keep a shared system correct and releasable while many engineers change it at the same time. Past a certain team and system size, informal coordination and late validation stop working. This is where things usually start to hurt.
What CI and CD Actually Mean
Continuous Integration means changes merge to trunk frequently and are validated automatically against the system as a whole. Batch size stays small, integration is routine, and feedback on breakage arrives fast enough to act while the change is still fresh in someone’s head.
Continuous Delivery means the system stays in a deployable state and the path to production is automated and repeatable. Releases stop being special events and become a routine capability. Enabling incomplete or even conflicting functionality to coexist safely in production is a core capability of this model — and I’ll cover the mechanisms behind that (feature flags, dark launches, and related patterns) in a dedicated follow-up article.
The defining traits here are short feedback loops and constrained change size.
The Problem CI/CD Solves
When integration and delivery are infrequent, the same failure pattern shows up over and over:
- Parallel work drifts apart until merging becomes a design exercise
- Incorrect assumptions survive too long without system-level validation
- Releases bundle many unrelated changes, making failures harder to diagnose and roll back
This is how teams end up “busy all sprint” and still afraid to deploy. Most of the effort goes into reconciling and debugging oversized change sets instead of building new capability.
CI/CD solves the fundamental problems: large batches and slow feedback. The system absorbs change continuously instead of in periodic, destabilizing shocks.
CI/CD as Continuous Validation
CI/CD turns correctness from a phase into an ongoing property of the system. Every merged change revalidates that the system still builds, integrates, and passes automated checks. Breakages map to small diffs, and detection happens quickly enough for teams to respond without archaeology.
Continuous Delivery extends this into production. If every commit could be deployed, deployment risk is driven mainly by change size. Small, frequent releases are safer because failures are easier to isolate, understand, and recover from.
For teams, this doubles as a coordination mechanism. System health is visible through automated signals, not buried in tribal knowledge or deferred to a “hardening phase” that never goes smoothly.
What CI/CD Is Not
CI/CD is not synonymous with build automation, test automation, or having a deployment pipeline. Automating a slow, high-batch process just gives you a faster way to queue up risk.
If engineers merge to trunk only every few days or weeks, integration risk is still accumulating. If production releases happen weekly, monthly, or less, release risk is still being stored in large batches. Calling this CI/CD doesn’t change the underlying physics.
A practical litmus test is frequency: if code is not integrated at least daily and the system is not releasable to production at least daily, the core risk-reduction properties of CI/CD are not in place. Many teams have sophisticated pipelines and are still operating a high-batch delivery model with better dashboards.
Evidence This Works
This isn’t just practitioner folklore. The DORA research program and the findings published in Accelerate consistently show that teams with high deployment frequency, short lead time from commit to production, low change failure rates, and fast recovery from incidents outperform peers in both speed and stability.
According to the 2021 Accelerate State of DevOps Report (see p. 11), Elite performers achieve the following compared to Low performers:
- Deployment Frequency: 973x more frequent (Multiple times per day vs. once per month/year).
- Lead Time for Changes: 6,570x faster (Under 1 hour vs. more than 6 months).
- Change Failure Rate: 3x lower (0-5% vs. 30-40%).
- Time to Restore Service: 2,600x faster (Under 1 hour vs. weeks).
These results match the mechanism: smaller changes, validated earlier and released routinely, are easier to reason about, test, and recover from. As summarized in the DORA Core Principles, the gains come from reduced batch size and tighter feedback loops—not from automation alone.
