Comprehensive Guide to Blue-Green and Canary Deployments in Azure Container Apps: Detailed Strategies and Best Practices

Introduction

In modern cloud-native application development, minimizing downtime and mitigating deployment risks are critical. Blue-green and canary deployments are two proven strategies that help achieve these goals by enabling safe and controlled rollouts of new application versions. This comprehensive guide offers an in-depth look into how you can implement these deployment patterns in Azure Container Apps, leveraging features like revisions, traffic weights, and revision labels.

Understanding Blue-Green and Canary Deployments

Blue-Green Deployment

Blue-Green Deployment is a release strategy aimed at reducing downtime and rollback risks during application updates. It involves maintaining two identical environments:

Blue environment: Runs the current stable application version serving production traffic.
Green environment: Runs the new application version for testing and validation.

Once the green environment is verified, production traffic is switched from blue to green, making green the new production environment. The previous blue environment remains intact, enabling quick rollbacks if issues arise.

Canary Deployment

While this post focuses primarily on blue-green deployments, canary deployments can be seen as a gradual traffic shifting strategy where a small percentage of production traffic is routed to a new version to monitor its behavior before a full rollout.

Azure Container Apps supports both patterns through traffic splitting and multiple active revisions.

Why Use Azure Container Apps for These Deployments?

Azure Container Apps provide a serverless environment for containerized applications with built-in support for revision management and traffic splitting. This enables:

Seamless creation of multiple active revisions for different app versions.
Fine-grained control over traffic distribution by revision labels.
Easy rollback and testing capabilities via domain label routing.

Setting Up Blue-Green Deployment in Azure Container Apps

Prerequisites

An Azure Container Apps environment.
Azure CLI installed and configured.
Container images tagged with commit hashes or unique version identifiers.

Step 1: Create a Container App with Multiple Active Revisions

Enable multiple active revisions and assign deterministic revision names using commit hashes. This facilitates easy identification and management of different application versions.

export APP_NAME=my-containerapp
export APP_ENVIRONMENT_NAME=my-env
export RESOURCE_GROUP=my-resource-group

# Current production commit
export BLUE_COMMIT_ID=fb699ef
# New version commit
export GREEN_COMMIT_ID=c6f1515

az containerapp create --name $APP_NAME \
  --environment $APP_ENVIRONMENT_NAME \
  --resource-group $RESOURCE_GROUP \
  --image mcr.microsoft.com/k8se/samples/test-app:$BLUE_COMMIT_ID \
  --revision-suffix $BLUE_COMMIT_ID \
  --env-vars REVISION_COMMIT_ID=$BLUE_COMMIT_ID \
  --ingress external \
  --target-port 80 \
  --revisions-mode multiple

# Route 100% traffic to the blue revision
az containerapp ingress traffic set \
  --name $APP_NAME \
  --resource-group $RESOURCE_GROUP \
  --revision-weight $APP_NAME--$BLUE_COMMIT_ID=100

# Label the current revision as blue
az containerapp revision label add \
  --name $APP_NAME \
  --resource-group $RESOURCE_GROUP \
  --label blue \
  --revision $APP_NAME--$BLUE_COMMIT_ID

Step 2: Deploy the Green Revision

Create a new revision with the updated application image and assign it the green label. This revision initially receives no production traffic.

az containerapp update --name $APP_NAME \
  --resource-group $RESOURCE_GROUP \
  --image mcr.microsoft.com/k8se/samples/test-app:$GREEN_COMMIT_ID \
  --revision-suffix $GREEN_COMMIT_ID \
  --set-env-vars REVISION_COMMIT_ID=$GREEN_COMMIT_ID

az containerapp revision label add \
  --name $APP_NAME \
  --resource-group $RESOURCE_GROUP \
  --label green \
  --revision $APP_NAME--$GREEN_COMMIT_ID

Step 3: Testing the Green Revision

Azure Container Apps automatically provide label-specific FQDNs for each revision, enabling isolated testing.

export APP_DOMAIN=$(az containerapp env show -g $RESOURCE_GROUP -n $APP_ENVIRONMENT_NAME --query properties.defaultDomain -o tsv | tr -d '\r\n')

# Test the production (blue) revision
curl -s https://$APP_NAME.$APP_DOMAIN/api/env | jq | grep COMMIT

# Test blue label FQDN
curl -s https://$APP_NAME---blue.$APP_DOMAIN/api/env | jq | grep COMMIT

# Test green label FQDN
curl -s https://$APP_NAME---green.$APP_DOMAIN/api/env | jq | grep COMMIT

This step ensures the green revision behaves as expected before routing live traffic.

Step 4: Switching Traffic to Green Revision

Once the green revision passes all tests, switch 100% of production traffic to it.

az containerapp ingress traffic set \
  --name $APP_NAME \
  --resource-group $RESOURCE_GROUP \
  --label-weight blue=0 green=100

The green revision now becomes the production environment.

Step 5: Rollback Strategy

If any issues arise post-deployment, rollback is straightforward by redirecting traffic back to the blue revision.

az containerapp ingress traffic set \
  --name $APP_NAME \
  --resource-group $RESOURCE_GROUP \
  --label-weight blue=100 green=0

This rollback ensures minimal user impact.

Step 6: Prepare for the Next Deployment Cycle

After a successful deployment, roles swap: green becomes stable production, and blue is used for the next release.

# New commit for next blue revision
export BLUE_COMMIT_ID=ad1436b

az containerapp update --name $APP_NAME \
  --resource-group $RESOURCE_GROUP \
  --image mcr.microsoft.com/k8se/samples/test-app:$BLUE_COMMIT_ID \
  --revision-suffix $BLUE_COMMIT_ID \
  --set-env-vars REVISION_COMMIT_ID=$BLUE_COMMIT_ID

az containerapp revision label add \
  --name $APP_NAME \
  --resource-group $RESOURCE_GROUP \
  --label blue \
  --revision $APP_NAME--$BLUE_COMMIT_ID

Best Practices for Blue-Green Deployments in Azure Container Apps

Use deterministic revision suffixes: Use unique, meaningful revision suffixes like commit hashes or build numbers to avoid confusion and ensure traceability.
Test thoroughly on green label FQDN: Leverage label-specific domains for comprehensive validation before switching production traffic.
Automate deployments with IaC: Use Bicep or ARM templates to manage deployments declaratively and reduce human errors.
Monitor performance and logs carefully: Integrate Azure Monitor and Application Insights to track the health of new revisions.
Implement gradual traffic shifts for canary: Instead of immediate 100% traffic switch, consider incremental traffic shifting for safer rollouts.

Canary Deployments: Extending Blue-Green with Traffic Weights

Azure Container Apps traffic splitting supports weighted routing, enabling canary deployments where a fraction of user traffic is routed to a new revision while the rest continues to use the stable revision. For example:

{
  "traffic": [
    {
      "revisionName": "myapp--fb699ef",
      "weight": 90,
      "label": "blue"
    },
    {
      "revisionName": "myapp--c6f1515",
      "weight": 10,
      "label": "green"
    }
  ]
}

This approach allows monitoring new code under real conditions with limited impact.

Real-World Scenario: E-Commerce Platform Deployment

Imagine an e-commerce platform running on Azure Container Apps. The team wants to deploy a new recommendation engine version without impacting customers during peak sales.

Current stable version runs on blue revision.
New engine deployed to green revision and tested thoroughly through green label FQDN.
Traffic is gradually shifted from blue to green (e.g., 10% increments) leveraging canary deployment principles.
Performance and errors monitored using Application Insights dashboards.
After successful validation, the green revision receives 100% traffic, becoming the new production.
Rollback to blue is immediately available if critical issues emerge.

This methodology minimizes downtime, reduces risk, and ensures a smooth user experience.

Conclusion

Blue-green and canary deployment strategies are essential for modern, resilient cloud applications. Azure Container Apps provides powerful native features like revision management and traffic splitting to implement these strategies effectively. By following the detailed steps and best practices outlined above, development teams can confidently roll out new application versions with minimal downtime and rapid rollback capabilities.

Additional Resources

Author: Joseph Perez

Published on: 2025-06-11