Part 3

CI/CD and mechanical checks

2 min read

3.1 The words, first

CI, continuous integration: on every change, automatic checks run (build, tests, lint) to catch regressions early. CD, continuous deployment or delivery: once verified, code flows to preprod then prod. A pipeline is that chain of steps. A gate is any automatic check that can block the line.

3.2 What automation costs, and what it guarantees

Automation is not free. Every check costs time to run, money in compute, and attention (a noisy check gets ignored). So you choose a regime, not "all the checks." A lean regime runs the cheap, high-value checks on every change (does it build, does it type-check, does a fast style pass) and saves the expensive ones (full end-to-end, load tests) for the moments that matter.

Honest note, because this book doesn't oversell: on my own products, a full automated test suite in the pipeline is often not wired in the first version. It's a deliberate early trade-off, added after launch. What does run automatically: the site redeploys on push, and the build must pass or nothing ships. The backend deploys by hand, on purpose. That mix, automatic on the site and manual on the backend, is a stable choice, not an unfinished chore. Say what you do and what you don't.

The honest version of a trade-off has two halves: name it as a deliberate choice, and name the trigger that flips it. "No automated test suite in the pipeline yet, because early on manual QA over a small surface is faster; we add the suite the moment the surface grows past what one person can check by hand, or the first regression reaches a user." A trade-off with a trigger is a plan. A trade-off without one is a hole you're pretending is a plan.

3.3 Blocking vs informational

Not every check should block. Some stop the line: the build fails, nothing ships. Some only inform: a warning you read and decide on. Know which is which, because a check you think is protecting you might only be whispering.

3.4 The ways a gate lies, and how to fix it

This is Law 5 made practical. A gate can pass while protecting nothing. It scans the wrong area. It only sees files already saved to version control, so brand-new code reads as "all clear." Its search pattern misses the real shape of the code. The runner counts "nothing to do" as a success. A test suite exists but is wired to run nowhere, so it passes by never running.

The fix is a discipline. Before you trust a check on new ground, make it fail on purpose. Then freeze one known-good case and one known-bad case as tests, so the check can always tell "working" apart from "inert." And keep it quiet: a gate that cries wolf gets switched off by the very people it was meant to protect.