Skip to content
Your First Change

Your First Change

The other pages explain one stage each. This one walks the whole path once, in order, so you can see how the handoffs connect.

Before you write code

  • Find the on-call rotation for the service you are about to touch. You will want it later, and looking it up now costs nothing.
  • Decide whether this needs a flag. Anything user-visible, anything touching money or data, anything you cannot cleanly revert. See Feature Rollout.
  • Decide what you will measure. If the change is supposed to improve something, the event that proves it must exist before the rollout — see Product Events.

Opening the change

  • Keep the diff scoped. Review latency scales worse than linearly with size.
  • Write a description that answers why, not what — the diff already says what.
  • Link the preview environment once it is up.

While it is in flight

  • A red check is yours to fix; push another commit to the same PR.
  • A merge-queue failure on a PR that was green usually means main moved. Re-read the failure against current main rather than assuming a flake — see the merge queue.
  • A stalled rollout has a specific signature. Find the last completed step in the deploy sequence and look at the next hop.

After it merges

Merging is the middle of the story.

  1. Confirm the artifact reached production — a green PR is not a deployed change.
  2. Start the exposure ramp deliberately, with the guardrails you chose earlier.
  3. Watch your own telemetry, not just the platform dashboards. You know what this change was supposed to move.
  4. When the rollout is complete, remove the flag. The change is not finished while a dead branch is still evaluated on every request.

If something goes wrong

In order of speed, which is the order you should try them:

  1. Disable the flag. Seconds. Scoped exactly to your change.
  2. Revert the deploy. One rollout, restoring the last good digest. No build.
  3. Roll forward with a fix. A full pipeline run. Correct when the first two cannot work — a migration, a data change, a broken dependency — and slowest by a wide margin.
Diagnose after mitigating, not before. The change is reproducible in a branch; the outage is not reproducible anywhere else.