how we build · part four
The Pipeline
Three environments, one trunk, conventional commits with scenario names. The pipeline as a chain of catches at increasing resolution — including security, secrets, and integrity. Migration discipline for schemas that change safely.
Events in this phase. Daily over the board continues — pipeline failures surface here. Pipeline runs on every push automatically. Environment health checked weekly by the tech lead.
Three environments, three purposes
| Environment | Purpose | Who touches it | Real users? |
|---|---|---|---|
| development | Local machines and shared dev servers. Where code is written and first verified. Anything that breaks here is caught cheaply. | Developers only | Never |
| staging | A mirror of production with production-like data. Where the team verifies the full chain before release. SLO confirmation happens here. | Team — PO, QA, designer, tech lead | Never |
| production | Live. Real users. Real data. Real consequences. Nothing reaches production unless it has passed staging and the release gate. | Nobody directly. Only via pipeline. | Always |
The rule that is never broken: no developer makes a change directly in production. No "quick fix." No database edit without going through the pipeline. Every exception creates a gap in the chain that will surface as a bug nobody can explain.
Trunk-based development
One main branch — the trunk. Feature branches are short-lived: a developer branches, works on a single story, and merges back when the pipeline passes. Long-lived branches are deferred integration — the longer you wait to merge, the more expensive the merge becomes. Feature flags are what make continuous deployment safe — code can be merged and deployed while invisible to users.
Deployment and release are separate decisions, made at different times, by different people. This is the single most important distinction in the volume.