Designing a continuous integration pipeline

Goal

Verify every change automatically against the same checks, quickly enough that a broken build is noticed and fixed within minutes.

Prerequisites

A build that runs from a clean checkout with declared dependencies, and a test suite that does not depend on a developer's machine.

Steps

1. Order the stages from cheap to expensive: dependency install with a cache, formatting and lint checks, unit tests, integration tests against real services in containers, then packaging.
2. Fail fast: stop at the first failing stage and report the exact command that failed.
3. Make the pipeline definition part of the repository, reviewed like code; pin action or image versions.
4. Run the same pipeline for pull requests and for the integration branch; the integration branch additionally publishes artifacts.
5. Measure pipeline duration and keep it in the range people are willing to wait for (Fowler's guidance is on the order of ten minutes); split or parallelise when it grows.
6. Treat a red integration branch as the top priority; do not stack more changes on it.

Expected result

Every merged change was built and tested in a clean environment; failures point to a specific stage; pipeline results are visible to the whole team.

Limits and test basis

A pipeline can only verify what tests cover. Caching speeds things up but can hide dependency drift; rebuild from scratch periodically. The stage order is a recommendation from practice, not a rule from the cited sources.