Delivery Pipeline
An interactive map of how code reaches production — branch, PR checks and previews, staging on dev, the Release Candidate gate, and the automated release on main.
Every change follows the same path: a feature branch cut from dev, a pull
request that must clear CI and a Supabase preview branch, integration on dev
(which is staging), and finally a Release Candidate PR into main — the only
merge that reaches production, guarded by the full CI matrix plus the e2e
suite and followed by an automated tag, GitHub Release, and Linear sync.
Click any stage or CI-job chip to see what it does, when it runs, and where it is defined. Hovering highlights how a stage connects to the rest of the pipeline.
Feature branch
PR → dev
Merge to dev
RC PR → main
Merge to main
Git
GitHub Actions
Deploys & Previews
Release
Select a stage or CI job above to see what it does, when it runs, and where it is defined.
How To Read This
- Columns are the five moments in a change's life, left to right. Lanes are the actors: what happens in git, what GitHub Actions validates, what gets deployed or previewed, and what the release automation produces.
- The diagram is hand-curated. Each CI node links to the exact lines of
ci.ymlit describes — if the workflow changes, follow the links and updatepipeline-data.tsalongside it. - The prose deep-dives live in Git Workflow, Continuous Integration, Database Workflow, and Release Automation.