Aliases: Continuous Integration, Continuous Delivery, Deployment pipeline
CI/CD
Automating the path from code commit to production — continuous integration tests every change, continuous delivery ships it safely.
Last reviewed: July 25, 2026
What is CI/CD?
CI (continuous integration): every commit automatically builds and runs tests, so broken changes surface in minutes, not at release time. CD: passing builds are automatically packaged and deployed — continuous delivery keeps a human approval before production; continuous deployment removes it. Tools: GitHub Actions, GitLab CI, and cloud-native options (CodePipeline, Cloud Build), usually building container images as the deployable artifact.
Why it’s the highest-leverage DevOps investment
DORA’s research is unambiguous: teams that deploy frequently in small batches have lower failure rates and recover faster — small changes are easy to review, test, and roll back. The pipeline is what makes small-batch shipping cheap enough to do constantly. A team deploying quarterly and a team deploying daily aren’t practicing different levels of caution; they’re carrying different amounts of risk per release.
Anatomy of a solid pipeline
Commit → lint + unit tests (< 5 min, the fast feedback loop) → build image → integration tests → deploy to staging → automated smoke tests → production via progressive delivery: canary (route 5% of traffic, watch metrics, expand) or blue-green (stand up the new version, switch, keep the old warm for instant rollback).
Cost reality
CI compute is cheap; slow pipelines are expensive — a 40-minute pipeline caps everyone’s iteration speed and silently costs more than any runner bill. Optimize wall-clock time: caching, parallelization, test splitting. The other hidden cost is flaky tests — once developers rerun red builds on reflex, the pipeline has stopped protecting you.
What people get wrong
- Secrets in pipeline configs. CI systems are a top attack target (they hold deploy keys to everything); use OIDC-based short-lived cloud credentials, not stored secrets.
- A deploy pipeline with no rollback pipeline. Shipping fast without reverting fast is half a system.
- Gating on 100% test coverage. Coverage is a diagnostic, not a goal; a fast, trusted suite beats a slow, complete one.
Continuous Delivery vs. Continuous Deployment
Within CI/CD, “continuous delivery” and “continuous deployment” are often used interchangeably but describe a meaningful distinction: continuous delivery means every code change that passes automated tests is automatically prepared for release (built, tested, packaged) but requires a human decision to actually deploy it to production, while continuous deployment goes one step further, automatically deploying every change that passes tests directly to production with no manual approval step at all. Organizations vary in which model they adopt based on their risk tolerance and the maturity of their automated testing — continuous deployment requires very high confidence in automated tests to be safe, since there’s no human checkpoint before changes reach real users, which is why many teams use continuous delivery with a manual approval gate even when their pipeline is otherwise fully automated.
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.