What is continuous integration? CI/CD and DevOps glossary

Continuous integration

Also called: CI, continuous integration pipeline, CI pipeline, CI pipelines

Definition

The practice of merging small changes into a shared branch often, with every push automatically built and tested so breakages surface within minutes.

Continuous integration (CI) means developers merge small changes into the main branch frequently, and a server builds the code and runs the automated tests on every push or pull request. The point is fast feedback: if a change breaks something, the author finds out while the change is still fresh, not days later during a big merge.

Example (GitHub Actions)

A minimal pipeline that runs the test suite on every pull request and on pushes to main:

name: CI
on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm test

If npm test exits with a non-zero code, the job fails and the pull request shows a red check. Combined with branch protection that requires this check, broken code cannot be merged.

What a tester owns in CI

Which tests run where. Fast unit and API tests on every pull request; slower end-to-end suites on merge or on a schedule. A pull request pipeline that takes 40 minutes stops being used.
Signal quality. A flaky test in a blocking job trains people to click “re-run”. Quarantine flakes so a red build always means something.
Artefacts. Publish reports, traces and screenshots from failed runs so nobody has to reproduce a failure locally just to see it.
Parallelism. Sharding a long suite across several machines keeps feedback time flat as the suite grows.

How it differs from CD

Continuous delivery extends CI: every build that passes is packaged and kept ready to release, usually through staging environments. Continuous deployment goes one step further and releases every passing change to production automatically. CI is the foundation of both; without a trustworthy test suite on every commit, neither is safe.

Common mistakes

Running CI only nightly, letting the main branch stay red for days, and treating the pipeline as the place where tests are written rather than where they are run. CI is a team habit as much as a tool: small merges, fix-or-revert when the build breaks.