CI/CD Pipeline

In short: An automated process that runs tests, builds and delivers the software on every code change — Continuous Integration / Continuous Delivery (or Deployment).

In more detail: CI means that changes are tested and merged frequently and automatically (instead of rare, large manual integrations). CD builds on this and automatically delivers tested changes into a test or production environment. Usually runs on every Git push or pull request.

In Depth

Pipeline stages

A typical pipeline consists of several consecutive stages, each automatically aborted as soon as one fails — saves time, since there’s no point continuing if the first step already fails:

1. Build: compile/bundle code, install dependencies.
2. Test: run automated tests (unit tests, integration tests).
3. Lint/static analysis: automatically check code quality and style, often also security scans.
4. Deploy: actually deliver the checked version (test, staging or production environment).

A minimal configuration (e.g. for GitHub Actions) looks like this:

on: push
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install
      - run: npm test
      - run: npm run build

CI vs. CD vs. continuous deployment

The core idea behind Continuous Integration is to uncover integration problems early and in small pieces, instead of only tackling them right before a big release (“integration hell” — a historically notorious problem when several developers work isolated on features for weeks and have to laboriously merge their changes at the end). Continuous Delivery means every successfully tested change could be delivered at any time (the last step, however, often remains a manual click, e.g. because a release date should be deliberately controlled); Continuous Deployment goes a step further and delivers automatically with no manual approval step, as soon as all checks pass — the most consistent form, but one that requires very reliable automated tests to not be risky.

Practical benefit

The economic core of CI/CD: the later a bug is found, the more expensive it is to fix — a typo caught during local testing costs seconds; the same bug only discovered after a production deployment through customer complaints can cost hours or days of investigation and reputational damage. CI/CD pipelines move bug discovery as early as possible in the development process.

Caching and parallelisation

With larger projects, the pipeline’s own runtime becomes a concern: dependencies (e.g. node_modules) are cached between runs instead of being downloaded fresh every time, and independent stages (e.g. linting and unit tests) run in parallel instead of sequentially, to shorten the wait for a result — with frequent commits, even a small time saving per run quickly adds up to noticeably more productive development.

See also: Git, GitHub