The Assembly Line
designing CI/CD pipelines that earn trust
A pipeline's job isn't to run fast. It's to make "green" mean something specific enough that nobody has to double-check it by hand.
Continuous integration and continuous delivery get talked about as one phrase, but they answer two different questions. CI asks: does this change integrate cleanly with everything else? CD asks: can we get a validated change into production without a human re-deriving trust in it by hand each time? A pipeline is what turns both questions into something that runs automatically, every time, whether or not anyone's watching.
01The four stages that matter
Pipelines accumulate steps over time — linting, security scans, notifications — but almost all of that sits on top of four stages that carry the actual weight.
Each stage should answer exactly one question, and a failure at any stage should point unambiguously at which question failed. A pipeline that bundles build and test into one step tells you something's wrong without telling you whether the code compiles or the code is correct — two very different problems with the same red X.
stages:
# 01 — does it compile
build:
run: npm run build
# 02 — is the behavior correct
test:
needs: [build]
run: npm test -- --ci
# 03 — ship the exact artifact that was tested
deploy:
needs: [test]
run: deploy-tool release --artifact build/
# 04 — confirm it's actually serving traffic correctly
verify:
needs: [deploy]
run: smoke-test --url $DEPLOY_URLNotice the artifact discipline in that last comment: the thing deployed to production should be the exact build that tests ran against — not a fresh rebuild from the same commit. Rebuilding at deploy time reopens the door for "it passed CI but the deployed version is different" in ways that are miserable to debug.
02What "green" is allowed to mean
A pipeline is a trust contract with the team. If green sometimes means "actually fine" and sometimes means "flaky test, just rerun it," the signal degrades fast — and once people learn to distrust red, they start merging past it, which is the one outcome the whole pipeline existed to prevent.
- Flaky tests get fixed or deleted, not rerun into submission. A test that fails 5% of the time for no code-related reason is actively teaching the team to ignore failures.
- Non-deterministic steps (network calls, timing-dependent assertions) get isolated so their flakiness doesn't take the whole pipeline's credibility down with it.
- Slow pipelines get parallelized, not skipped. A 40-minute pipeline invites people to merge before it finishes "just this once" — which is how the contract quietly stops being a contract.
The pipeline isn't there to catch mistakes. It's there so nobody has to trust their own memory of whether they checked.
03Where pipelines lose the team's trust
Silent skips
A stage that's configured to skip under certain conditions — missing credentials, a timeout — but still reports green teaches the team that green doesn't always mean what it says.
Deploy stage that also runs tests "for safety"
Duplicating test logic in the deploy stage instead of trusting the test stage's result usually means the two stages can disagree — and now there are two sources of truth instead of one.
No verify stage at all
Deploy succeeding only means the bytes moved. Without an automated check that the new version is actually healthy in production, "deployed" and "working" quietly become the same word when they aren't.
Manual approval gates with no criteria
A human "approve to deploy" button with no written bar for what to check becomes a formality within a few weeks — clicked reflexively, adding delay without adding review.
04Rollback is part of the pipeline
A pipeline that can ship but can't cleanly reverse a bad deploy has only done half the job. Treating rollback as a first-class, tested path — not a manual scramble reconstructed under pressure — is what makes it safe to ship frequently in the first place. The confidence to deploy on a Friday afternoon doesn't come from the deploy stage; it comes from trusting the stage that undoes it.
