Skip to main content
This page explains how code moves from merge to production and why each step exists.

​
The Cycle

​
Steps & Why

​
Staging — every merge

Each merge to main builds a version.sha.beta image, deploys it to staging, and runs the E2E suite against staging. The e2e-staging check on the commit records the result. Why: Every commit gets tested on a real deployment, and the result stays on the commit for the gate to read.

​
Cloud gate — by hand

continuous-delivery-cloud.yml takes the newest main commit whose e2e-staging passed. It runs the E2E matrix (four configurations) and the upgrade test from the last self-hosted release on the image staging built. The run summary lists the tickets in the candidate. One approval in the production environment deploys the image to the canary and then to the fleet. Why: Cloud gets the exact image that staging tested. The gate runs by hand until the E2E suite covers more of the product; then it runs Sunday to Thursday at 8 AM UTC, so each deploy is small.

​
Self-hosted

Self-hosted releases use release-self-hosted.yml. See Releases.

​
Putting It Together

​
Overrides

  • Hotfix: Merge the fix into main, then run continuous-delivery-cloud.yml by hand with hotfix_prs. Cloud gets only those PRs on top of what it runs, after the same checks and approval. The rest of main waits for the next full gate run.
  • Emergency: Use emergency-cloud-deploy.yml to deploy directly to production, bypassing staging entirely. Use sparingly.

​
FAQ

Q: I merged at 10 AM UTC on a Wednesday. When does my code reach production? It deploys to staging immediately. If e2e-staging passes, the next Cloud gate run picks it up, and it reaches Cloud when the deploy is approved. Until the gate runs on a schedule, that is when the release captain starts it.