CI/CD automates the path from "a developer wrote code" to "that code is safely running in production." Here's what each half means, and what actually happens in between.
CI (Continuous Integration) = automatically build and test every code change as soon as it's merged, instead of waiting.
CD (Continuous Delivery/Deployment) = automatically prepare (Delivery) or actually ship (Deployment) that change to production.
Before CI/CD became standard practice, teams would let changes accumulate for weeks before a big, risky 'release day' — integrating everyone's work at once and discovering conflicts and bugs all at the same time. CI/CD flips that: integrate constantly, in small pieces, and catch problems within minutes of them being introduced.
The value isn't really automation on its own — it's the frequency. Running tests once a month, even automatically, doesn't give you the same benefit as running them on every single commit. Continuous integration means every change gets validated in isolation, so when something breaks, it's almost always obvious which change caused it. This is the opposite of the old "integrate everything right before release" model, where a bug could be hiding among dozens of merged changes.
Most modern CI/CD tools let you define the pipeline itself — build steps, test commands, deployment targets — in a configuration file stored in the same repository as the application code (e.g. a `.github/workflows/` file for GitHub Actions, or a `.gitlab-ci.yml` for GitLab). This means the pipeline is versioned, reviewable, and changes to it go through the same code review process as the application itself.
A well-built pipeline typically won't let a change through unless it passes multiple gates: the build must succeed, unit and integration tests must pass, code coverage must meet a threshold, static analysis/linting must pass, and security scanning must find no critical vulnerabilities. Production deployments often add an extra gate — a manual approval step, even in an otherwise-automated pipeline, for changes that carry higher risk.
CI stands for Continuous Integration — frequently merging code changes into a shared branch, with automated builds and tests running on every merge. CD stands for either Continuous Delivery (code is automatically prepared and ready to deploy, but a human triggers the actual release) or Continuous Deployment (every change that passes the pipeline is automatically released to production with no human step).
Both automate everything up through having a release-ready build. Continuous delivery stops there and requires a human to click "deploy." Continuous deployment goes one step further and deploys automatically with no manual approval, as long as all automated checks pass. Many teams use "CD" ambiguously to mean either, so it's worth clarifying which one a team means.
A common sequence is: (1) a developer pushes code, (2) the pipeline automatically builds the application, (3) automated tests run (unit, integration, sometimes end-to-end), (4) static analysis/security scanning runs, (5) a deployable artifact (like a container image) is produced and stored in a registry, (6) the artifact is deployed to a staging environment, and (7) for continuous deployment, it's automatically promoted to production if all checks pass — or held for manual approval in continuous delivery.
Manual deployments are slow, inconsistent, and error-prone — a step forgotten under deadline pressure can break production. CI/CD makes every deployment repeatable and automated, catches bugs earlier (when a small, isolated change breaks something, it's easy to pinpoint which commit caused it), and lets teams ship smaller, more frequent changes instead of large, risky releases.
Popular CI/CD platforms include GitHub Actions, GitLab CI/CD, Jenkins, CircleCI, and Azure DevOps Pipelines. Most integrate directly with the code repository, triggering automatically on events like a push or pull request, and support defining the pipeline steps as configuration files stored alongside the code itself ("pipeline as code").