Pull Request to Production

This is the path you personally walk. Each column is a phase, each row is who or what is acting, and the bottom lane is where changes go when something says no.

The gates, in order

1. CI suite — blocking, automated

Lint, unit tests, and contract tests run against your branch. This gate exists to fail before anyone spends review time on the change.

A red check sends the change back to you immediately. It is not a queue you can wait out.

2. Preview environment — informational

A per-PR deploy of your branch. It converts review from reading a diff to trying the change. If your repository provides one, link it in the PR description; reviewers who can click something respond faster than reviewers who cannot.

3. Code review — blocking, human

Codeowner approval. This is the only gate whose latency you influence socially rather than technically, and the only one where diff size dominates everything else. A 400-line PR does not take twice as long to review as a 200-line one; it takes considerably longer, and the review is worse.

4. Merge queue — blocking, automated

The queue rebases your change onto current main and re-runs the tests against that result, not against the base you branched from.

This is the step people are most often surprised by: a PR that was green for two days can fail here because someone else’s merge conflicted semantically with yours. The tests were never wrong; they were answering a question about an older main.

5. Staging soak — blocking, automated

The merged artifact runs in staging under synthetic traffic. The exit condition is time plus SLOs, not just “it started up”. A soak that has not finished is not a failure — it is the gate doing exactly what it was built to do.

6. Canary release — progressive

Production, at 1% of traffic first. See Deploy Request for what the rollout actually does, call by call.

The recovery path

The bottom lane is drawn deliberately, because pretending failure is exceptional is how teams end up with no practised recovery.

Send Back covers both a red check and a requested change. In both cases the fix is the same shape: push another commit to the same PR. Nothing is lost, and the pipeline re-runs from the top.

Revert is different, and worth internalising before you need it:

Before you hit merge

• Do you know who is on call for the service you are touching?
• Is the new behaviour behind a flag? If not, merging and launching are the same event, and you have given up your fastest mitigation.
• Could this change be reverted cleanly? Migrations, event-schema changes, and anything that writes state need a deliberate answer here, because a digest restore will not undo them.