07 - Revisions and Traffic Splitting¶

Azure Container Apps revisions provide immutable deployment snapshots. Use them for safe releases, canary traffic, and quick rollback.

Infrastructure Context

Service: Container Apps (Consumption) | Network: VNet integrated | VNet: ✅

This tutorial assumes a production-ready Container Apps deployment with a custom VNet, ACR with managed identity pull, and private endpoints for backend services.

flowchart TD
    INET[Internet] -->|HTTPS| CA["Container App\nConsumption\nLinux Python 3.11"]

    subgraph VNET["VNet 10.0.0.0/16"]
        subgraph ENV_SUB["Environment Subnet 10.0.0.0/23\nDelegation: Microsoft.App/environments"]
            CAE[Container Apps Environment]
            CA
        end
        subgraph PE_SUB["Private Endpoint Subnet 10.0.2.0/24"]
            PE_ACR[PE: ACR]
            PE_KV[PE: Key Vault]
            PE_ST[PE: Storage]
        end
    end

    PE_ACR --> ACR[Azure Container Registry]
    PE_KV --> KV[Key Vault]
    PE_ST --> ST[Storage Account]

    subgraph DNS[Private DNS Zones]
        DNS_ACR[privatelink.azurecr.io]
        DNS_KV[privatelink.vaultcore.azure.net]
        DNS_ST[privatelink.blob.core.windows.net]
    end

    PE_ACR -.-> DNS_ACR
    PE_KV -.-> DNS_KV
    PE_ST -.-> DNS_ST

    CA -.->|System-Assigned MI| ENTRA[Microsoft Entra ID]
    CAE --> LOG[Log Analytics]
    CA --> AI[Application Insights]

    style CA fill:#107c10,color:#fff
    style VNET fill:#E8F5E9,stroke:#4CAF50
    style DNS fill:#E3F2FD

Revision Traffic Splitting¶

graph TD
    INGRESS[Ingress] -->|90%| V1[Revision v1]
    INGRESS -->|10%| V2[Revision v2]

Prerequisites¶

Completed 06 - CI/CD with GitHub Actions
At least two deployed images/tags

Define promotion criteria before traffic split

Decide in advance which metrics (error rate, latency percentile, saturation) must stay within threshold before increasing canary traffic.

Step-by-step¶

Set standard variables (reuse Bicep outputs from Step 02)

RG="rg-myapp"
BASE_NAME="myapp"
DEPLOYMENT_NAME="main"

APP_NAME=$(az deployment group show \
  --name "$DEPLOYMENT_NAME" \
  --resource-group "$RG" \
  --query "properties.outputs.containerAppName.value" \
  --output tsv)

ACA_ENV_NAME=$(az deployment group show \
  --name "$DEPLOYMENT_NAME" \
  --resource-group "$RG" \
  --query "properties.outputs.containerAppEnvName.value" \
  --output tsv)

ACR_NAME=$(az deployment group show \
  --name "$DEPLOYMENT_NAME" \
  --resource-group "$RG" \
  --query "properties.outputs.containerRegistryName.value" \
  --output tsv)

ACR_LOGIN_SERVER=$(az deployment group show \
  --name "$DEPLOYMENT_NAME" \
  --resource-group "$RG" \
  --query "properties.outputs.containerRegistryLoginServer.value" \
  --output tsv)

| Command | Purpose |
|---|---|
| `APP_NAME=$(az deployment group show --name "$DEPLOYMENT_NAME" --resource-group "$RG" --query "properties.outputs.containerAppName.value" --output tsv)` | Captures the deployed app name so revision and traffic commands apply to the correct Python app. |
| `ACA_ENV_NAME=$(az deployment group show --name "$DEPLOYMENT_NAME" --resource-group "$RG" --query "properties.outputs.containerAppEnvName.value" --output tsv)` | Captures the environment name so environment-scoped revision checks stay aligned with the deployment. |
| `ACR_NAME=$(az deployment group show --name "$DEPLOYMENT_NAME" --resource-group "$RG" --query "properties.outputs.containerRegistryName.value" --output tsv)` | Captures the registry name that stores the revision images referenced during promotion. |
| `ACR_LOGIN_SERVER=$(az deployment group show --name "$DEPLOYMENT_NAME" --resource-group "$RG" --query "properties.outputs.containerRegistryLoginServer.value" --output tsv)` | Captures the registry login server used to assemble image tags for new revisions. |

Switch to multiple revision mode

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

Command	Why it is used
`az containerapp revision set-mode ...`	Runs the Azure CLI operation required by the documented step.

???+ example "Expected output"

"Multiple"

Deploy a new version to create a new revision

az acr build --registry "$ACR_NAME" --image "$BASE_NAME:v3" ./app

az containerapp update \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --image "$ACR_LOGIN_SERVER/$BASE_NAME:v3"

Command	Why it is used
`az acr build --registry ...`	Builds and pushes the container image to Azure Container Registry.

???+ example "Expected output" az acr build takes 1-2 minutes. The az containerapp update returns:

{
  "latestRevision": "<your-app-name>--xxxxxxx",
  "name": "<your-app-name>",
  "provisioningState": "Succeeded"
}

List revisions and choose targets

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

Command	Why it is used
`az containerapp revision list ...`	Lists revisions so rollout state, traffic, and health can be verified.

???+ example "Expected output"

Name                                     Active    CreatedTime
---------------------------------------  --------  -------------------------
<your-app-name>--0000001                 True      2024-01-15T10:00:00+00:00
<your-app-name>--0000002                 True      2024-01-15T10:15:00+00:00

    JSON equivalent (`--output json`):
    ```json
    [
      {
        "name": "<your-app-name>--0000001",
        "active": true,
        "createdTime": "2024-01-15T10:00:00+00:00"
      },
      {
        "name": "<your-app-name>--0000002",
        "active": true,
        "createdTime": "2024-01-15T10:15:00+00:00"
      }
    ]
    ```

Apply canary traffic split (90/10)

az containerapp ingress traffic set \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --revision-weight "<stable-revision>=90" "<canary-revision>=10"

Command	Why it is used
`az containerapp ingress traffic ...`	Runs the Azure CLI operation required by the documented step.

???+ example "Expected output"

[
  {
    "revisionName": "<your-app-name>--0000001",
    "weight": 90
  },
  {
    "revisionName": "<your-app-name>--0000002",
    "weight": 10
  }
]

Verify applied traffic routing:

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

Command	Why it is used
`az containerapp ingress show ...`	Reads ingress configuration such as exposure, target port, transport, and affinity.

???+ example "Expected output"

{
  "allowInsecure": false,
  "external": true,
  "fqdn": "<your-app-name>.<hash>.<region>.azurecontainerapps.io",
  "targetPort": 8000,
  "transport": "Auto",
  "traffic": [
    {
      "revisionName": "<your-app-name>--0000001",
      "weight": 90
    },
    {
      "revisionName": "<your-app-name>--0000002",
      "weight": 10
    }
  ]
}

Rollback instantly if errors increase

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

Command	Why it is used
`az containerapp ingress traffic ...`	Runs the Azure CLI operation required by the documented step.

???+ example "Expected output"

[
  {
    "revisionName": "<your-app-name>--0000001",
    "weight": 100
  }
]

Deactivate bad revision after confirmation

az containerapp revision deactivate \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --revision "<canary-revision>"

Command	Why it is used
`az containerapp revision deactivate ...`	Runs the Azure CLI operation required by the documented step.

???+ example "Expected output"

"Deactivate succeeded"

Verify revisions and traffic in Azure Portal¶

[Observed] ca-sample-d38538. Container App. Revisions and replicas. Create new revision. Save. Refresh. Deployment mode. Send us your feedback. Learn more. Active revisions. Inactive revisions. Replicas. Name. Date created. Running status. View Logs. Label. Traffic. ca-sample-d38538--0uzoi59. 6/3/2026, 10:34:26 PM. Running. View details. Show Logs. 100. %. 1. Show replicas. Application. Revisions and replicas. Containers. Scale. Volumes. Settings. Networking. Ingress. Custom domains. CORS. Security. Monitoring. Log stream. Logs. Console. Alerts. Metrics.

[Inferred] The Deployment mode toolbar action appears to map to the same lever set by az containerapp revision set-mode --mode multiple in Step-by-step Step 2. The Create new revision toolbar action is consistent with the new-revision effect of az containerapp update --image in Step-by-step Step 3. The Active revisions and Inactive revisions tabs are consistent with the revision list and revision deactivate operations in Step-by-step Steps 4 and 7. The Traffic column value 100 % for ca-sample-d38538--0uzoi59 appears to map to the per-revision weight set by az containerapp ingress traffic set --revision-weight in Step-by-step Steps 5 and 6.

[Not Proven] Additional revision detail and traffic-split detail are not visible on this view.

Operational guidance¶

Pair canary rollout with telemetry checks (errors, latency, saturation).
Keep one prior known-good revision for emergency rollback.
Use KEDA metrics and revision health together for rollout decisions.

Do not leave stale canary revisions active

After rollback or promotion, deactivate obsolete revisions to reduce operational confusion and prevent unintended traffic assignment during future updates.

Advanced Topics¶

Route traffic by labels for blue/green style releases.
Combine revisions with Dapr service invocation for progressive migration.
Automate canary promotion in CI/CD using policy checks.

07 - Revisions and Traffic Splitting¶

Revision Traffic Splitting¶

Prerequisites¶

Step-by-step¶

Verify revisions and traffic in Azure Portal¶

Operational guidance¶

Advanced Topics¶

See Also¶

Sources¶