Deploy

Goal

Take a merged change from main and see it running for all users, with a verified canary step in between.

Prerequisites

• Change merged to main (we deploy from trunk — see Progressive Delivery).
• Familiarity with the observability dashboard for the service being deployed.

Steps

1. CI triggers the deploy

Every merge to main triggers the CI pipeline: run tests, build container image, push to Artifact Registry, deploy to Cloud Run canary.

2. Watch the canary

The canary serves a small fraction of traffic. The automated promotion gate compares canary SLO metrics — latency, error rate, user-journey success — against the current production.

Monitor the release dashboard; in most cases, automated promotion handles it. Manual override is available when you want to pause or abort.

3. Promote or abort

• Automated promote. If canary metrics are within tolerance for the watch window, traffic is shifted to 100%.
• Automated abort. If canary burn rate exceeds the threshold, traffic is routed back and the team is paged.
• Manual promote. For releases with user-facing changes, a human can promote or hold.

4. Close the release

Once promotion is complete, close the release ticket, announce in the release channel, and verify the user-facing change behaves as expected.

Verification

• Current traffic is 100% on the new revision.
• SLO dashboards are green.
• Feature flags for the new release (if any) are in the expected state.

Troubleshooting

• Canary aborted. Check the release dashboard for the failing signal. Common causes: a dependency change that increases latency, an environment variable missing in the new revision.
• Deploy stuck "in progress." Check Cloud Run logs for the service; a crash-loop will block promotion.
• SLO burn after promotion. Roll back via the dashboard; file the incident ticket.

See Progressive Delivery for the broader stance and Operations / Runbooks for post-deploy recovery procedures.