What is CI/CD actually doing?

Continuous integration verifies that changes work together, continuously; continuous delivery keeps the software always in a releasable state; continuous deployment goes further and releases automatically. The three are distinct and the terms are used interchangeably far too often.

Continuous integration (CI). Every change is merged into a shared branch frequently — ideally at least daily — and an automated build and test run verifies it.

The problem it solves: integration pain. Before CI, developers worked on branches for weeks and merged at the end, discovering conflicts and incompatibilities all at once and in the worst possible combination. CI makes integration a small, constant activity rather than a large, painful event, and this is the actual insight — the automation is a means to it.

The requirement people skip: CI only works if changes are merged frequently. A team running automated builds on long-lived feature branches has the tooling and not the practice, and still has the problem.

Continuous delivery (CD). Every change that passes is automatically prepared for release, so the software is always deployable. Deployment itself is a business decision, taken by pressing a button.

Continuous deployment. Every change passing the pipeline is released to production automatically, with no human step. Requires very high confidence in the tests and in the ability to detect and reverse problems.

What a pipeline typically does: compile or build; run unit tests; run static analysis and linting; check dependencies for known vulnerabilities; build an artefact; run integration tests; deploy to a staging environment; run further tests; and deploy.

What makes a pipeline useful rather than ignored:

Speed. A slow pipeline is worked around. Feedback in minutes changes behaviour; feedback in an hour does not.

Reliability. Flaky tests are the most damaging failure, because once people learn to re-run rather than investigate, the pipeline has stopped providing information while still consuming time.

Clear failure output, so the cause is identifiable without archaeology.

The same process for every environment, so production deployment is routine rather than exceptional.

The underlying goal is reducing the risk and cost of each individual change, so that changes can be small and frequent — which is what makes software safe to alter.