CI vs continuous delivery vs continuous deployment

Published 21 October 2026

Picture a team that merges everyone's work once a month. Merge day takes three days. Half the conflicts are in code nobody remembers writing, and the release that follows breaks in ways no single change explains. Now picture a team that merges every few hours and ships to production twenty times a day. The second team has fewer outages, not more, because every change is small enough to understand and to undo.

The three terms describe how far a team has moved towards the second picture:

• Continuous integration (CI): everyone merges into the main branch at least once a day, and every push is built and tested automatically. A red build is fixed first, before new work.
• Continuous delivery: on top of CI, every change that passes the pipeline is ready to release. Going to production is a button anyone on the team can press, at any time.
• Continuous deployment: there is no button. Every change that passes goes to production automatically, usually gradually and behind feature flags.

So: CI keeps the code working. Continuous delivery keeps it releasable. Continuous deployment releases it. "CD" can mean either of the last two, so ask which one people mean.

Where the ideas came from#

Grady Booch used the phrase continuous integration in 1991, and Extreme Programming made it a daily practice in the late 1990s. Martin Fowler's article on it, first written in 2000, is still the standard reference. Jez Humble and David Farley's 2010 book Continuous Delivery added the second step: treat the release itself as a boring, automated, repeatable process, so it can happen whenever the business wants.

The pipeline, and why speed matters#

A pipeline is the list of jobs that run on every push: install, lint, type check, tests, build, deploy a preview. Its most important number is how long the author waits for an answer. Under about ten minutes, people wait for it. Over twenty, they switch tasks, come back later, and start batching changes to wait less often, which brings back exactly the big risky merges CI was meant to remove.

Try the three changes teams usually make first.

Beyond those three:

• Run only what changed. In a monorepo, Nx and Turborepo work out which packages a change affects and skip the rest, and remote caching reuses results another machine already computed.
• Fail fast. Put lint and type checks where they finish first, so a typo fails in one minute, not twenty.
• Keep the main branch green. A merge queue (built into GitHub since 2023, and in GitLab as merge trains) tests each pull request on top of everything queued before it, so two changes that pass alone but break together never both land.

How teams set it up#

This is a typical GitHub Actions workflow for a TypeScript service. Jobs in the matrix run in parallel, npm downloads are cached, and the browser tests are split across four machines.

name: ci
on: [pull_request, merge_group]   # merge_group runs it again inside the merge queue
 
jobs:
  checks:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        task: [lint, typecheck, test:unit, test:integration]   # four jobs at once
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 24, cache: npm }
      - run: npm ci
      - run: npm run ${{ matrix.task }}   # integration tests start Postgres with Testcontainers
 
  e2e:
    runs-on: ubuntu-latest
    strategy:
      matrix: { shard: [1, 2, 3, 4] }
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 24, cache: npm }
      - run: npm ci && npx playwright install --with-deps
      - run: npx playwright test --shard=${{ matrix.shard }}/4

Around the workflow, four settings do as much work as the YAML:

1. Branch rules on main: nobody pushes directly, every change needs a pull request, a review and green required checks.
2. A preview deployment per pull request (Vercel, Netlify and most platforms do this), so a reviewer in another time zone can click the change instead of imagining it.
3. Dependency updates as small automatic pull requests from Dependabot or Renovate, which CI then tests like any other change.
4. No long lived cloud keys in CI. GitHub Actions, GitLab and others can log in to AWS, GCP and Azure with short lived OIDC tokens, so there is no secret to leak.

Measuring it: the DORA metrics#

The DORA research program, now run by Google Cloud, has surveyed tens of thousands of engineers since 2014. It found that four numbers separate strong delivery teams from weak ones, and that speed and stability go together rather than against each other:

• Deployment frequency: how often you ship to production.
• Lead time for changes: from commit to running in production.
• Change failure rate: how many deploys cause a problem that needs fixing.
• Recovery time: how long it takes to restore service when one does.

The first two are speed, the last two are stability. Interviewers like this list because it shows you think about delivery as something to measure, not a matter of opinion.

In the interview#

Checkpoint#