CI/CD
What a pipeline must enforce, in what order, and what it should not try to be.
Overview
This document covers why continuous integration is the first automation worth building, what belongs in a pipeline and in what order, why it must run in the environment that actually builds the artifact, and where automated deployment stops being obviously correct.
Why This Exists
This is written from an absence rather than a success, which makes it unusually specific. Every guarantee across the systems behind AZOTH, the authorisation posture test, the migration invariants, the storage round trip, every test file, was enforced only when somebody remembered to run it locally. Each was carefully built. None was enforced. That is tolerable while one person works on one system. It stops being tolerable the moment code is shared, because that is when the blast radius of an unnoticed regression goes from one system to several. The gap was named as the largest single one in the engineering story, and naming it did not close it. Building the pipeline did.
Integration before deployment
What belongs in the pipeline, and in what order
It has to run where the artifact is built
A pipeline that stays green
Where automated deployment stops being obvious
Related Principles· 3
Related Documents· 3
Referenced By· 5
Version History
- v0.1.0
Initial structure and metadata established.
- v0.2.0
Written from real experience, most of it from the cost of not having a pipeline. Separates integration from deployment, orders the stages by cost, records why verification must run where the artifact is built, gives the two rules that keep a pipeline credible, and marks where automated deployment stops being obviously correct.