What is CI/CD?

What is CI/CD?

CI/CD is a software practice in which teams merge code changes often and an automated pipeline builds, tests, and prepares each one for release. CI stands for continuous integration. CD stands for continuous delivery or continuous deployment, depending on whether a person approves each release. The goal is software that stays ready to release.

CI/CD is a practice, not a product, and it is a core part of DevOps, which joins building software with running it. A CI service runs the pipeline, usually from a configuration file stored in the repository, e.g. a GitHub Actions workflow. The pipeline runs the same checks on every change, so a problem appears soon after the change that caused it, not weeks later at release time.

GitHub's Octoverse 2025 counted an average of 43.2 million pull requests merged each month, up 23% on the year before. Each merge is a point where a pipeline can check a change before users receive it.

How does a CI/CD pipeline work?

A CI pipeline is the ordered set of automated steps that runs each time code is pushed or merged. A CI/CD pipeline adds the steps that package the result and release it. A typical run has these stages:

1. A developer or a coding agent pushes a change to a branch, and the push starts a run.
2. The CI service hands the job to a runner, usually a fresh virtual machine or container. The runner checks out the change, installs the dependencies, and builds the software. A failed build stops the run.
3. The runner runs the fastest checks next, e.g. a linter, and then the unit tests in the test suite.
4. The runner runs the slower integration and end-to-end tests only after the fast checks pass.
5. The CI service reports each result on the pull request as a status check, and the team merges the change when the checks pass.
6. After the merge, the pipeline packages the build, deploys it to a staging environment, and runs smoke tests.
7. The pipeline releases the build to production, with a person's approval in continuous delivery and without it in continuous deployment.

Steps 1 to 5 are continuous integration. Steps 6 and 7 are the delivery or deployment half. The order puts cheap checks first, so a simple mistake fails the run early and the slow tests run only on changes that pass. Each run also works as regression testing, because the suite checks that behavior that worked before still works.

What are the types of CI/CD?

CI/CD covers three practices, and each one builds on the one before it.

Continuous integration

Continuous integration is the habit of merging each developer's work into the main branch often and testing every merge automatically. The International Software Testing Qualifications Board (ISTQB) definition stresses the automated build, and Martin Fowler stresses merging at least daily.

Continuous delivery

Continuous delivery extends CI so that every change that passes the pipeline is packaged and ready to release. A person decides when to release it, usually with one approval step. The release becomes a business decision, not a technical task.

Continuous deployment

Continuous deployment removes that approval step. Every change that passes the automated pipeline goes to production with no person in between. It puts the most weight on the tests, because they are the last check before users receive the change.

What is an example of a CI/CD pipeline?

Here is an illustrative example. Acme Co. sells furniture online, and its web store runs this GitHub Actions workflow on every pull request and every push to main:

name: ci
on:
  pull_request:
  push:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: npm ci
      - run: npm run build
      - run: npm run lint
      - run: npm test
      - run: npm run test:e2e

A developer at Acme asks a coding agent to "Let customers edit their delivery address during checkout." The agent changes the checkout code and opens a pull request. The run has these steps:

1. The runner checks out the pull request's merge with main, and npm ci installs the exact versions in the lockfile.
2. The build and the linter pass, and npm test reports 48 unit tests passed.
3. The end-to-end test adds 2 items to the cart, changes the address to "12 Elm Street," and fails. The address saved, but the cart emptied.
4. The pull request shows a failed check, and its log names the failing assertion.
5. The developer pastes the log into a new agent session, the agent fixes the code and pushes again, and the second run passes.
6. A reviewer merges the pull request, and a separate deploy workflow sends the build to staging, where the smoke tests pass.
7. A developer approves the release to production, which makes this pipeline continuous delivery, not continuous deployment.

This example is simplified. A real pipeline would also start the web store and a test database before the end-to-end test, and check database migrations.

What changes when a coding agent writes the code?

Coding agents raise the number of changes, and each change starts a pipeline run. Anthropic reported that its CI job volume grew 25-fold in six months as Claude came to write about 80% of its code. The growth forced a redesign of how it chooses which tests to run.

Linear reported that its test suites nearly quadrupled in 2026 as coding agents sped up shipping, and it had to rework CI to keep feedback fast. Slow feedback costs more with an agent, because the agent's session can end before the result arrives. An agent can also skip local checks, e.g. with git commit --no-verify, so CI can be the first check that runs on the change at all.

A failed check often appears on the pull request after the agent's output has said "done." The failure then has to be brought back to an agent, often by someone pasting the log into another session. Teams shorten that wait by running fast checks, e.g. a linter, inside the agent's loop before a push. A merge queue tests each approved pull request against the main branch and the changes ahead of it, so two agent changes that pass alone are also tested together.

What are the limits of CI/CD?

A pipeline makes checking routine, but it has limits that more automation does not remove:

• It checks only what its tests check. A green run shows that the checks that ran have passed, not that the change does what was asked.
• Someone has to choose the checks. The pipeline runs only the checks that people or agents wrote, so a team decides which risks get tests. Some risks, e.g. a confusing checkout form, still need a person to look.
• Flaky tests erode trust. A flaky test passes and fails on the same code. When people rerun red builds until they turn green, a real failure can pass unnoticed.
• Speed and depth pull against each other. A longer suite makes every run slower. A shortcut, e.g. running only the affected tests, can let a failure through.
• Staging is not production. Staging has no real users or real traffic, so some failures appear only after release. Some teams skip staging, release small changes straight to production, and watch their monitoring closely.

How is continuous delivery different from continuous deployment?

Continuous delivery and continuous deployment run the same pipeline and differ only in whether a person starts the release. With continuous delivery, a team can hold a passing change and release it when the business is ready. With continuous deployment, a team holds a change back by keeping it off the main branch or behind a feature flag. To do continuous deployment, a team must be doing continuous delivery, because both depend on a pipeline that keeps each change releasable.

What does CI/CD cover?

These CI/CD articles explain where checks run between a code change and a release:

• Pre-commit, pre-push, and CI checks run at three points on the way to a merge, from the developer's machine to the shared pipeline.
• Pre-commit hooks are scripts that Git runs before it records a commit, to lint, format, or test the staged changes.
• Agent hooks are scripts that a coding agent's harness runs at fixed points in its loop, e.g. when the agent tries to end its turn.
• Continuous integration merges each developer's work into the main branch often and builds and tests each merge.
• Quality gates measure a change against set criteria before it moves to the next stage.
• Shift-left testing moves testing and other quality checks earlier in development.
• Tests pass locally but fail in CI when an input that the tests never set differs on the CI machine.
• CI for coding agents becomes a bottleneck when agents push changes faster than runners can test them.

See every CI/CD article

How do you check what CI tests do not cover?

Keep the required CI checks fast. Tests in CI check only what someone wrote, so it also helps to run the software and try the workflow that the change touched.

RunStory runs your software against the change in a separate environment, tries relevant workflows, and checks the results. It sends reproducible failures back to your coding agent while you keep working. It is in private alpha for CLIs and web apps, and your team keeps the final release decision.

Join the RunStory alpha →

FAQs

What is the point of running unit tests on a CI server?

Running unit tests on a CI server checks each change outside the author's own setup, including changes from a coding agent that skipped local checks.

What should a CI/CD pipeline run first?

A CI/CD pipeline should run its fastest and cheapest checks first, e.g. a format check, and then the unit tests. Slower integration and end-to-end tests run after those pass, so a simple mistake fails the run early and costs little runner time.

Do you still need a test plan with continuous delivery?

A test plan is still useful with continuous delivery, because a pipeline runs only the checks that someone wrote. The plan records which risks get automated tests and which need a person to look, and the release still waits for a person to approve it.

Does CI/CD need a staging environment?

A staging environment is common in CI/CD but not required. Many pipelines deploy to staging and run smoke tests before production. Teams that skip staging usually release smaller changes and watch production monitoring after each release.