CI/CD
Also known as: Continuous Integration / Continuous Delivery
Frequent automated integration and deployment of small changes.
CI/CD comprises two related but distinct practices that together enable frequent, reliable software delivery. Continuous Integration (CI), articulated by Grady Booch and operationalized by Kent Beck within Extreme Programming in the late 1990s, prescribes that developers integrate their work into a shared mainline frequently (at minimum daily, ideally many times per day), with each integration verified by automated build and test suites. Martin Fowler's 2006 'Continuous Integration' article codified the practices: maintain a single source repository, automate the build, make the build self-testing, everyone commits to mainline daily, every commit triggers a build, fix broken builds immediately, keep builds fast, test in a clone of production, make build artifacts easy to access, automate deployment. Continuous Delivery (CD), substantially elaborated by Jez Humble and David Farley in Continuous Delivery (2010), extends CI by ensuring that the software is always in a deployable state and can be released to production at the push of a button. Continuous Deployment (also CD, distinguished by some authors) goes further: every change that passes automated tests is automatically deployed to production. Together CI/CD enables short feedback cycles, rapid iteration, and the practice of small, low-risk releases that DevOps and modern delivery practices depend on.
Core components
- Continuous Integration: shared mainline, frequent commits, automated build, automated test suite, broken-build priority
- Continuous Delivery: deployable state always, automated deployment pipeline, environment parity
- Continuous Deployment: every passing change deployed automatically
- Build pipeline with progressive validation stages
- Trunk-based development as enabler
- Feature flags for decoupling deploy from release
- Connection to TDD and test automation
- Integration with version control and infrastructure-as-code
Primary use case
Modern software delivery practice across most software-development contexts; foundation for DevOps and SRE delivery practices; basis for substantial commercial tooling ecosystem (Jenkins, GitHub Actions, GitLab CI, CircleCI, Argo CD, others); enables high-frequency deployment patterns associated with elite-performing teams (DORA research); foundation for safe production deployment in cloud-native systems.
Common criticisms
- 'CI/CD' as label is often invoked for pipelines that don't actually integrate continuously (long-lived branches with infrequent merges) — the form is adopted without the discipline
- tooling-heavy implementations can produce build pipelines that are themselves complex, brittle systems requiring maintenance
- flaky tests undermine the practice — when developers stop trusting the build, all CI benefits collapse
- the gap between CI passing and production-readiness is harder than many implementations admit
- deployment frequency without underlying engineering discipline (testing, observability, rollback) is dangerous
- CI/CD investment cost is substantial and frequently underestimated
- some development domains (regulated industries, embedded systems, mobile apps) have fundamental constraints on deployment frequency that CI/CD culture sometimes overlooks.
Lineage
- Child of
- Extreme Programming
- Siblings
- DevOps, Trunk-Based Development, Test-Driven Development, Site Reliability Engineering
- Derived from
- Extreme Programming