What Is a CI/CD Pipeline?

By Kaveh Alemi·Latchkey

A CI/CD pipeline is the automated sequence of stages a code change travels through, from commit to production, with a gate at each step.

A pipeline is the assembly line of software delivery. Each stage does one job, hands off to the next, and stops the line if something fails. Visualizing your delivery process as a pipeline makes it predictable and easy to improve.

What a pipeline is

A CI/CD pipeline is a defined series of automated stages, such as build, test, and deploy, that a change must pass through in order. Each stage either succeeds and passes the work forward, or fails and halts progress. The pipeline is usually triggered by a code event like a push or pull request.

Common stages

Source: a commit or pull request triggers the run.
Build: compile code and install dependencies.
Test: run unit, integration, and other automated tests.
Package: produce a versioned artifact.
Deploy: promote the artifact to staging, then production.

How the stages connect

Stages run in sequence, but independent work within a stage can run in parallel, for example testing on several operating systems at once. A failure in any stage short-circuits the rest, so you never deploy a build that did not pass its tests. Artifacts produced early are reused downstream rather than rebuilt.

An example pipeline

A four-stage pipeline outline

stages:
  - build      # compile + install deps
  - test       # unit + integration tests
  - package    # produce artifact
  - deploy     # staging -> production

Why pipelines matter

A pipeline turns a fuzzy, manual release process into something explicit and repeatable. Everyone can see where a change is, what passed, and what failed. Because the steps are defined in code, the process is versioned and reviewable like any other code. Faster runners shorten the whole pipeline, which is why teams invest in runner speed.

Applying this to your pipeline

Measure before changing. Most CI optimisation targets the wrong step because the slow one is assumed rather than timed.
Cache what is expensive to produce and cheap to validate, and key the cache to the exact tool version.
Fail fast: run the cheapest checks that can reject a change first, so an expensive job never starts on code that cannot pass.
Prefer determinism over speed when they conflict. A fast pipeline nobody trusts gets re-run, which is slower than a slow one that is believed.

Key takeaways

A pipeline is an ordered set of automated stages from commit to deploy.
A failure in any stage halts the rest, protecting production.
Defining the pipeline in code makes the process versioned and reviewable.