A DevOps engineer needs to safely roll out a new version of a Cloud Run service named `billing-api` in the `us-central1` region by creating a tagged revision, sending a small percentage of test traffic to it, and finally shifting all production traffic to the new revision once verified. Place the following `gcloud` CLI steps in the correct chronological order to complete this canary release workflow.
- 1Deploy a new revision of the `billing-api` service with the `--no-traffic` flag and a specific revision tag specified by `--tag=canary`.
- 2Test the new revision directly using its unique tagged URL (e.g., `https://canary---billing-api-uc.a.run.app`) to verify health.
- 3Update traffic allocation using `gcloud run services update-traffic billing-api --region=us-central1 --to-tags=canary=10` to send 10% of main traffic to the canary revision.
- 4Update traffic allocation using `gcloud run services update-traffic billing-api --region=us-central1 --to-latest` to route 100% of production traffic to the new revision.
Answer
The correct sequence to perform a tagged canary rollout on Cloud Run is: 1) Deploy the new revision with `--no-traffic` and `--tag=canary`, 2) Test the revision via its dedicated tag URL, 3) Update traffic to route 10% of production traffic to the `canary` tag, and 4) Route 100% of traffic to the new revision using `--to-latest`.
A standard zero-downtime canary deployment sequence in Cloud Run requires deploying the new code revision with no initial traffic allocation using `--no-traffic` while assigning a revision tag (`--tag`). Next, the engineer tests the container using the generated tag-specific URL. After successful direct verification, a small percentage of live production traffic is assigned to the tag using `gcloud run services update-traffic --to-tags`. Finally, after monitoring stability, 100% of live traffic is shifted to the latest revision.
Step-by-Step Solution
Key Concept
Cloud Run Traffic Splitting & Revision Tagging Workflow