The principle
Releases should be frequent, small and boring. Every change goes through the same path: a build that gives the same output from the same input on any machine, the same checks, the same deploy step, and a record of who changed what and when. Policy lives in the pipeline, so nobody has to remember it. Progressive delivery (canary, blue-green, feature flags) limits how many users a bad change reaches.
Source: CI/CD & Deployment and Progressive Delivery Patterns; Google's Release Engineering.
On this platform
- One path for every change. Every push to
mainruns one workflow with two jobs: the conformity checks, then the deploy to Pages, which runs only when the checks pass (Deploy pipeline, ADR-0002). It also runs every Monday at 06:17 UTC and by hand. - One gate for three sites. machinebehavior.io, tychat.io and uncovertechtalent.com run the same composite action, so a rule change reaches all three (Conformity gate).
- A failed check is a safe state. When a check fails, the deploy does not run and readers keep the previous build. On 2026-10-08 a link in a template string failed the check; the fix passed 81 seconds later and nobody outside saw the broken page (incident record, runbook).
- Every run is recorded. The gate commits its result to
conformity/latest.json; run artifacts are kept 90 days; the deploy exporter writes each run, step and check to Loki and Prometheus, and the Website deploys dashboard shows them. - High change rate. Several agent sessions push the same repository through the gate many times a day: 69 recorded runs between 2026-10-07 12:36 and 2026-10-09 13:36 UTC.
- Rollback. Undoing a live change is a revert pushed through the same gate. The handbook's rollback runbook is generic; the sites have no runbook of their own for it.
State
Partial. The gate and the deploy path are in place and recorded. Two parts are missing. The generated pages (docs, services, status) are built on the author's machine and committed; CI does not rebuild them, so a source edited without a build, or generated HTML edited by hand, deploys unnoticed (#40). And the observability stack has no pipeline: it is copied to its server by hand, with no gate in front of it (Eliminate toil). Canary releases are not used: Pages replaces the whole site at once, and the risk on a text site sits in the content, which the gate checks.
Services that name it
In a company of 10 to 200 people
- One pipeline per repository, the same stages for every team, and the deploy step only reachable through it.
- Build once in CI from a clean checkout and deploy exactly that artifact to every environment.
- Make rollback a deploy of the previous artifact, and practise it until it takes minutes.
- Add canaries and feature flags when there is traffic to split and a metric to judge the canary by.