What Is CI/CD? Continuous Integration vs Delivery vs Deployment (2026)

Most people who ask me what CI/CD is have already used it: they pushed a commit, a green tick appeared, and something got deployed somewhere. The acronym hides three different promises, though, and teams that blur them end up with a slow pipeline they call continuous delivery and a release process that still needs a Thursday change board. This post explains what CI/CD means in 2026: continuous integration vs continuous delivery vs continuous deployment, the stages a pipeline runs, what DORA's research says about speed and stability, why trunk-based development is the branching model CI assumes, what changes when an agent writes a growing share of the code, and which tools people use. It is written for beginners, but every number links to its source.

What is CI/CD, in one paragraph?

CI/CD is the practice of getting every code change integrated, built, tested and made ready for release automatically, so that shipping becomes routine instead of an event. CI stands for continuous integration. CD stands for either continuous delivery or continuous deployment, which are not the same thing.

Martin Fowler's continuous integration article, last revised in January 2024, is still the reference definition: every member of a team merges their changes into the shared mainline at least daily, and each integration is verified by an automated build that includes tests. DORA's continuous integration capability guide adds the operational detail: every commit triggers a build and automated tests that give feedback in a few minutes, and fixing a broken build takes priority over other work, or the change that broke it gets reverted.

The word people skip is integration. Fowler is blunt that running a CI server against long-lived feature branches is not continuous integration, because the work has not been merged with anyone else's and the hard part (discovering that your change and mine conflict) is postponed. A green tick on a three-week-old branch tells you that branch compiles. It tells you very little about the product.

Continuous integration vs continuous delivery vs continuous deployment

Fowler's continuous delivery entry defines delivery as building software so that it can be released to production at any time. Continuous deployment goes one step further: every change that passes the pipeline goes to production automatically. Delivery means you could deploy any green build today and may choose not to; deployment means the pipeline makes that choice for you. You cannot do continuous deployment without continuous delivery, and you cannot do either without continuous integration.

	Continuous integration	Continuous delivery	Continuous deployment
What is automated	Merge to trunk, build, tests on every commit	Everything up to a production-ready release, usually including a staging deploy	Everything, including the production deploy
Who decides to release	Out of scope	A person or business rule, on any day they like	The pipeline: green means live
Gate before production	None	Manual approval, change window or feature flag	Automated checks only (tests, canary analysis, SLOs)
Prerequisite	Version control, automated build and tests	Continuous integration	Continuous delivery
Source	Fowler, DORA	Fowler	Fowler

Which one should you aim for? Most teams I work with, especially regulated ones, stop at continuous delivery with an approval button in front of production. That is a respectable place to stop, provided the button could be pressed on any afternoon without a week of manual QA first. Otherwise it is a pipeline in front of a waterfall.

What are the stages of a CI/CD pipeline?

Tools differ, but almost every pipeline runs the same seven stages in the same order.

1. Trigger. A push or pull request starts the run. The pipeline definition lives in the repository, so a change to how you build is reviewed like any other change.
2. Build. Resolve dependencies from a lockfile, compile, lint. Same inputs, same output, which is why npm ci exists alongside npm install.
3. Test. Fast tests first. Fowler's guideline is a build of about ten minutes, and DORA's guide treats roughly ten minutes as the upper limit. Past that, people stop waiting and start batching changes.
4. Package. Produce one artifact, once: usually a container image identified by its content digest. DORA's guide says the package the CI build creates should be authoritative and used by every downstream process.
5. Deploy to staging and verify. Deploy that exact artifact automatically and smoke-test it.
6. Release to production. A person approves (delivery) or the pipeline proceeds (deployment). Canaries and feature flags make this step smaller; I compared them in Progressive Delivery in 2026.
7. Observe and roll back. Rolling back should mean redeploying the previous digest, not rebuilding last week's commit and hoping.

Here is the skeleton in GitHub Actions syntax. The full version with Docker builds, a registry and approvals is in my sibling guide, How to Build a CI/CD Pipeline With GitHub Actions.

# .github/workflows/ci.yml: the shape of a CI/CD pipeline (GitHub Actions)
name: ci
on:
  pull_request:            # CI: every proposed change
  push:
    branches: [main]       # CD: every merge to trunk
permissions:
  contents: read           # least privilege unless a job asks for more
jobs:
  test:                    # build + fast tests: minutes, not hours
    runs-on: ubuntu-24.04
    timeout-minutes: 10
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
      - uses: actions/setup-node@949feb2413d6458794dcd2491c4babbbce0c15c1 # v7.1.0
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test
  release:                 # package once, deploy that same artifact
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-24.04
    environment: production  # continuous delivery: put a required reviewer on this
    steps:
      - run: echo "build the image once, push it, deploy it by digest"

What does DORA's research say about CI/CD?

DORA (DevOps Research and Assessment, now part of Google Cloud) has surveyed software teams since 2014, and its metrics are the closest thing the industry has to a shared yardstick. The current metrics guide, updated on 5 January 2026, lists five, not the original four. Throughput is change lead time, deployment frequency and failed deployment recovery time. Instability is change fail rate and the newer deployment rework rate: unplanned deployments caused by a production incident.

The 2024 report was the last one to publish the familiar performance clusters:

DORA 2024 cluster	Share of respondents	Change lead time	Deployment frequency	Change fail rate	Failed deployment recovery
Elite	19%	Less than one day	On demand, multiple per day	5%	Less than one hour
High	22%	One day to one week	Daily to weekly	20%	Less than one day
Medium	35%	One week to one month	Weekly to monthly	10%	Less than one day
Low	25%	One to six months	Monthly to every six months	40%	One week to one month

Two things in that table are worth sitting with. The elite teams are faster and more stable at the same time, which is the core CI/CD argument: small, frequent, automated changes are safer than big, rare, manual ones. And the medium cluster has a lower change fail rate than the high cluster, 10 percent against 20, which is DORA reminding you that the clusters are a snapshot, not a ladder.

The 2025 report, built on nearly 5,000 respondents, replaced the clusters with seven team profiles, from "foundational challenges" to "harmonious high achievers". It found 90 percent of respondents using AI at work, with AI adoption now positively associated with delivery throughput and still negatively associated with stability. The 2024 announcement had put numbers on the earlier picture: as AI adoption increased, estimated throughput fell 1.5 percent and stability 7.2 percent. DORA is a careful survey, not a controlled experiment, so read these as associations.

Trunk-based development: the branching model CI assumes

DORA's trunk-based development guide calls it a required practice for continuous integration, and its thresholds are concrete: three or fewer active branches in the repository, branches merged to trunk at least once a day, and no code freezes or integration phases. Branches in trunk-based development typically live for hours, not weeks. The evidence comes from DORA's 2016 and 2017 data, where teams following these practices showed higher delivery and operational performance.

Trunk-based does not mean everyone pushes straight to main with no review. In practice it means short-lived branches, small pull requests reviewed the same day, branch protection that requires CI to pass, and feature flags to hide work that is merged but not finished. Release branches for old versions are fine. What hurts is the feature branch that diverges for a month and then needs a merge week. The GitFlow vs GitHub Flow vs trunk-based trade-offs are in Git Branching Strategies in 2026.

How AI-assisted code changes CI/CD in 2026

The volume going through pipelines is up sharply. GitHub's Octoverse 2025, covering September 2024 to August 2025, counts 43.2 million pull requests merged per month on average (up 23 percent), more than a million pull requests opened by the Copilot coding agent between May and September 2025, and 11.5 billion Actions minutes used by public projects, up 35 percent. When changes arrive faster than people can read them, the pipeline becomes the only reviewer that sees every line.

DORA's AI Capabilities Model lists seven capabilities that amplify AI's benefits, and three are CI/CD under another name: strong version control practices, working in small batches, and quality internal platforms. Google's write-up says frequent commits amplify AI's positive effect on individual effectiveness, and frequent use of rollback boosts AI-assisted teams. CI keeps the batches small; CD keeps the rollback cheap. The review side, including agents reviewing agents, is in CI/CD in 2026: Agents Opened 1M PRs in 5 Months.

Three practical consequences follow. Flaky tests get more expensive: Google reported that almost 16 percent of its tests showed some flakiness and about 84 percent of pass-to-fail transitions involved a flaky test, and an agent that retries until green will find your flakes before you do. The pipeline's permissions become a security boundary: in March 2025 the tj-actions/changed-files action was compromised (CVE-2025-30066) so that secrets could be read from workflow logs, and since August 2025 admins can fail any workflow that uses an action not pinned to a full commit SHA. And agents are moving into the pipeline itself: GitHub Agentic Workflows entered technical preview on 13 February 2026, with read-only permissions by default and writes only through pre-approved "safe outputs".

Adoption inside pipelines is still early. JetBrains' 2025 CI/CD survey of 805 people found 73 percent not using AI in their CI/CD workflows at all.

Which CI/CD tools are teams using in 2026?

The same JetBrains survey found GitHub Actions used by 62 percent of respondents for personal projects and 41 percent in organisations, with Jenkins and GitLab still heavily used in companies, and multi-tool setups common: 32 percent of organisations run two CI/CD tools and 9 percent run three or more, usually because a migration is half done. Versions were checked on each release page on 31 October 2026.

Tool	What it is	Latest release	Fits when
GitHub Actions	CI/CD built into GitHub, YAML workflows	Runner v2.338.2 (26 Oct 2026)	Code lives on GitHub
GitLab CI/CD	CI/CD built into GitLab	GitLab 19 series	Code on GitLab, or you want one self-managed product
Jenkins	Self-hosted automation server with plugins	LTS 2.580.2 (28 Oct 2026), Java 21 or 25	Existing investment, on-prem, unusual hardware
Argo CD	Pull-based GitOps CD for Kubernetes	v3.5.6 (20 Oct 2026)	Kubernetes deploys driven from Git, with a UI
Flux	Pull-based GitOps CD for Kubernetes	v2.10.0 (26 Oct 2026)	Kubernetes, composable controllers, no UI needed
Tekton Pipelines	Kubernetes-native pipeline resources	v1.18.0 LTS (29 Oct 2026)	You are building a CI platform on Kubernetes
Dagger	Pipelines written in a general-purpose language	v0.21.11 (21 Oct 2026)	The same pipeline locally and in any CI

One architectural split matters more than the brand. In push-based CD, the CI system holds production credentials and runs the deploy. In pull-based CD (GitOps), a controller inside the cluster watches a Git repository and pulls changes in, so CI never holds cluster credentials; Argo CD and Flux are compared in Argo CD vs Flux in 2026, and the hosted CI choice in GitHub Actions vs GitLab CI vs Jenkins in 2026.

Cost changed this year too. GitHub cut hosted runner prices by up to 39 percent on 1 January 2026, postponed its proposed $0.002-per-minute charge on self-hosted runners with no new date, and kept Actions free for public repositories. Private repositories on the Free plan now get $12 of included compute a month instead of a minute allowance.

FAQ

Is CI/CD the same as DevOps?

No. DevOps is the broader idea that the people who build software and the people who run it share responsibility for it. CI/CD is one of its core technical practices, the automated path from commit to production. A pipeline without that shared ownership tends to become a faster way to throw changes over the same old wall.

What is the difference between continuous delivery and continuous deployment?

With continuous delivery, every change that passes the pipeline is ready to release and a person or business rule decides when it goes live. With continuous deployment, every change that passes the pipeline goes to production automatically with no human step. Deployment requires delivery; delivery does not require deployment.

How long should a CI pipeline take?

Aim for feedback in under ten minutes for the checks that run on every commit. Fowler's ten-minute build guideline and DORA's continuous integration guide both land there. Slower suites can run after merge or in parallel, but the fast path that gates a pull request should stay short enough that people wait for it.

Do small teams need CI/CD?

Yes, and they get the most from it relative to effort, because a two-person team has nobody to do a manual release checklist reliably. Start with a pipeline that lints and tests every pull request and deploys main to one environment. Add approvals, staging and provenance when the second customer complains.

If I were setting up or auditing a pipeline this quarter, I would check five things in this order: that main gets merged into at least daily, that the artifact is built once and deployed by digest, that the fast path finishes in under ten minutes with flaky tests quarantined rather than retried, that every third-party action is pinned to a commit SHA under a read-only default token, and that the five DORA metrics come out of deploy logs instead of a quarterly survey. Agent-authored changes go through exactly the same gates. None of that requires a new tool. It requires deciding what "green" is allowed to mean.

Related: DevOps Still Matters in 2026: AI Cut Delivery Stability 7.2%, GitHub Actions Security in 2026: 76 Hijacked Tags and the Fixes That Work and Platform Engineering vs DevOps vs SRE in 2026.