Pipeline Stages That Mean Something

Why this matters

A team has a pipeline with nine stages, all green, and broken code reaches production twice a month. The stages run lint after deploy, tests against a different artifact than the one shipped, and a manual approval nobody reads. Green means the steps ran, not that the claims hold. Each stage must prove exactly one thing, in an order where the cheapest proof runs first.

Concepts

The canonical stages: checkout, build, fast checks (lint, unit tests), slow checks (integration, security scan), package (artifact plus metadata), and deploy (or publish for review). Each stage declares inputs, the command set, and outputs; a stage that produces no recorded output proves nothing and exists for decoration. Fail fast is economics: a three-second lint failure should never wait behind a twenty-minute integration suite. Order by cost, ascending.

Stages communicate through artifacts, not vibes. The build stage emits the exact artifact later stages test and later still ships; if tests run against a rebuild instead of the packaged artifact, the pipeline certified one thing and shipped another. Lesson 3 makes this airtight. Manual gates belong where human judgment changes the outcome (production deploy of a risky change), not as confetti between automated steps where they only add queue time.

Pipeline as code means the definition lives in the repo, reviewed like application code, with history. Click-built pipelines drift: nobody knows what step 4 does after the third hotfix, and reproducing a run from six months ago is archaeology. Versioned definitions also make the pipeline itself testable: change a step, watch a run, read the record.

Worked example

A pipeline runs unit tests after the Docker build and deploy to staging before integration tests. Two faults: the twenty-minute build runs before the ten-second unit suite, so every typo costs twenty minutes; and staging receives code the integration suite later rejects, so staging is routinely broken. The repair reorders to checkout, lint plus unit, build, integration against the built image, package, then staging. Expected reading: typo feedback in seconds, staging only ever holds integration-passed images, and each stage's output names the artifact hash it certified. Lab L16 replays this shape with a deliberately failing test that must halt the line.

The common wrong move

Adding stages to fix discipline. A team whose tests are flaky adds a retry stage, then a manual approval, then a notification stage, until the pipeline is a maze nobody trusts and everybody bypasses with admin rights. Stages do not create rigor; each stage must have a rejection it actually performs. Count rejections per stage over a month: a stage that never rejects is a candidate for deletion.

Lab and next step

Lab L16 builds a pipeline where a failing test genuinely stops everything downstream, with the halt visible in the run record. Next, lesson 2 goes deep on the gates themselves: what blocks, what warns, and what is theater.