Skip to content

Revision Operations

This guide focuses on operating revisions in production: activating/deactivating revisions, splitting traffic safely, and performing fast rollbacks.

Prerequisites

  • App deployed in a Container Apps environment
  • A known stable revision available for rollback
export RG="rg-aca-prod"
export APP_NAME="app-python-api-prod"
export ENVIRONMENT_NAME="aca-env-prod"

Revision Mode Management

Use multiple revision mode for canary or A/B releases.

az containerapp revision set-mode \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --mode multiple

Review revisions and health state:

az containerapp revision list \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --output table

Use Activity Log for deployment event timeline:

az monitor activity-log list \
  --resource-group "$RG" \
  --max-events 20 \
  --status Succeeded \
  --output table

Traffic Splitting

Shift a small percentage to the candidate revision first.

az containerapp ingress traffic set \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --revision-weight "${APP_NAME}--stable=90" "${APP_NAME}--candidate=10"

Gradually increase traffic only when SLOs remain healthy.

Rollback Procedure

Return 100% traffic to last known good revision:

az containerapp ingress traffic set \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --revision-weight "${APP_NAME}--stable=100"

Deactivate failed revision:

az containerapp revision deactivate \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --revision "${APP_NAME}--candidate"

Verification Steps

az containerapp ingress traffic show \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --output json

Example output (PII masked):

[
  {
    "revisionName": "app-python-api-prod--stable",
    "weight": 100
  }
]

Troubleshooting

New revision is healthy but receives no traffic

  • Confirm app is in multiple revision mode.
  • Check exact revision name from revision list command.
  • Ensure ingress is enabled before setting traffic weights.
az containerapp show \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --query "properties.configuration.ingress" \
  --output json

Revision Promotion Workflow

flowchart TD
    A[Deploy Candidate Revision] --> B[Assign 5-10% Traffic]
    B --> C[Observe Errors Latency Restarts]
    C --> D{Within SLO?}
    D -->|Yes| E[Increase Traffic in Stages]
    D -->|No| F[Rollback to Stable Revision]
    E --> G[Promote 100% Traffic]
    F --> H[Deactivate Failed Revision]
Scenario Recommended Action Why
New feature with unknown risk Multiple revision mode + staged traffic Limits blast radius
Security hotfix Fast deploy + focused health checks Reduces exposure window
Runtime regression detected Immediate traffic rollback Restores service quickly
Stable period after rollout Deactivate stale revisions Reduces operational noise

Name revisions with meaningful image tags

Immutable image tags mapped to commit SHA or release IDs make revision rollback decisions deterministic during incidents.

Do not promote traffic without replica health checks

A revision can exist but still fail under real load. Validate health, restart count, and error rate before increasing traffic.

Revision Health Validation Commands

az containerapp revision list \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --query "[].{name:name,active:properties.active,replicas:properties.replicas,healthState:properties.healthState,runningState:properties.runningState}" \
  --output table

az containerapp ingress traffic show \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --output table

Advanced Topics

  • Use labels for stable/candidate routing patterns.
  • Implement progressive delivery with automated rollback on alert.
  • Keep at least one warm standby revision for instant failback.

See Also

Sources