Blue-Green Deployments in Azure

The blue-green concept

In a blue-green deployment, you maintain two environments:

Blue is the currently live environment serving production traffic. Blue is running the previous stable version.

Green is the standby environment where you deploy and validate the new version. Green receives no production traffic while you are testing it.

When the new version is validated in the green environment, you cut all traffic from blue to green. If the new version has a problem, cut all traffic back from green to blue. Blue is still running the previous version, ready to accept traffic.

The key requirement: both environments must be running and warm. The old environment must stay alive until you are confident in the new version — you cannot shut it down the moment the traffic switches.

Blue-green with App Service deployment slots

App Service’s deployment slot swap is the canonical blue-green mechanism in Azure. The production slot is blue. The staging slot is green. You deploy the new version to staging, validate it, then swap slots. The swap changes which slot the production hostname routes to.

What happens during a slot swap:

1. Azure applies the target slot’s configuration (app settings, connection strings) to the source slot instances so they warm up with production configuration.

2. Azure sends requests to the source slot (staging) and waits for healthy responses, confirming the application has completed startup.

3. Azure atomically switches the internal routing so the production hostname now points to the previously-staging infrastructure.

4. The previously-production infrastructure (now serving no traffic) becomes the staging slot.

# 1. Deploy new version to staging slot
az webapp deployment slot create \
  --name app-myapp-prod \
  --resource-group rg-prod \
  --slot staging \
  --configuration-source app-myapp-prod

# 2. Deploy application code to staging slot
az webapp deploy \
  --name app-myapp-prod \
  --resource-group rg-prod \
  --slot staging \
  --src-path ./publish/app.zip \
  --type zip

# 3. Validate the staging slot manually or run automated smoke tests
# Staging slot URL: https://app-myapp-prod-staging.azurewebsites.net

# 4. Swap: staging slot becomes production, production becomes staging
az webapp deployment slot swap \
  --name app-myapp-prod \
  --resource-group rg-prod \
  --slot staging \
  --target-slot production

# 5. Verify the new version is live
az webapp show \
  --name app-myapp-prod \
  --resource-group rg-prod \
  --query "{state:state, url:defaultHostName}"

# 6. If rollback is needed: swap back
az webapp deployment slot swap \
  --name app-myapp-prod \
  --resource-group rg-prod \
  --slot staging \
  --target-slot production

Slot-sticky vs swapped settings

By default, all app settings and connection strings swap with the slots. If your staging slot has a staging database connection string, that connection string moves to production after the swap — which is usually wrong.

Mark settings as “Deployment slot setting” (slot-sticky) to keep them bound to a specific slot. Slot-sticky settings do not swap — they stay with the slot they are configured on, regardless of swap direction.

# Mark a connection string as slot-sticky (stays on this slot, does not swap)
az webapp config connection-string set \
  --name app-myapp-prod \
  --resource-group rg-prod \
  --slot staging \
  --settings DefaultConnection="Server=sql-staging.database.windows.net;..." \
  --connection-string-type SQLAzure \
  --slot-setting true

Typical slot-sticky settings: database connection strings (staging DB vs production DB), logging endpoints (staging Log Analytics vs production), feature flag service endpoints, third-party API keys that are environment-specific.

Blue-green in AKS with Service selector changes

In AKS, blue-green is implemented using two Deployments (blue and green) and a single Service. The Service selects pods via a label. Changing the Service’s selector label from blue to green switches all traffic to the new version:

# production-service.yaml
# The selector determines which pods receive traffic
apiVersion: v1
kind: Service
metadata:
  name: myapp-production
  namespace: production
spec:
  selector:
    app: myapp
    version: blue   # Change this to "green" to switch traffic
  ports:
    - port: 80
      targetPort: 8080

# Deploy the green (new) version
kubectl apply -f myapp-green-deployment.yaml -n production

# Validate green pods are healthy
kubectl get pods -l app=myapp,version=green -n production
kubectl logs -l app=myapp,version=green -n production --tail=50

# Switch traffic: update Service selector from blue to green
kubectl patch service myapp-production \
  -n production \
  --type='json' \
  -p='[{"op": "replace", "path": "/spec/selector/version", "value": "green"}]'

# Verify new pods are receiving traffic
kubectl get endpoints myapp-production -n production

# Rollback: switch selector back to blue
kubectl patch service myapp-production \
  -n production \
  --type='json' \
  -p='[{"op": "replace", "path": "/spec/selector/version", "value": "blue"}]'

Keep the blue Deployment running until you are fully confident in the green version. Only delete the blue Deployment after a suitable validation period.

Blue-green in Container Apps

Container Apps revisions provide a clean blue-green mechanism. Deploy the new version as a new revision with 0% traffic. Test it directly using the revision-specific URL. When ready, shift 100% of traffic to the new revision in one step:

# Deploy new revision (green) with 0% traffic initially
az containerapp update \
  --name myapp \
  --resource-group rg-prod \
  --image myregistry.azurecr.io/myapp:v2.0 \
  --revision-suffix green-v2

# Test the green revision directly via its revision URL
# Format: https://<app-name>--<revision-suffix>.<env-domain>
az containerapp revision show \
  --name myapp \
  --resource-group rg-prod \
  --revision myapp--green-v2 \
  --query "properties.fqdn"

# Validate green revision (no production traffic yet)
# Run smoke tests against the revision-specific URL

# Switch: move 100% of traffic to green revision
az containerapp ingress traffic set \
  --name myapp \
  --resource-group rg-prod \
  --revision-weight myapp--green-v2=100

# Rollback: switch back to the previous revision
az containerapp ingress traffic set \
  --name myapp \
  --resource-group rg-prod \
  --revision-weight myapp--blue-v1=100

Blue-green vs canary: when to use each

Blue-green is the right choice when:

• The new version has been thoroughly tested in staging and you have high confidence in it.
• The change is large and a mixed-version state (some users on v1, some on v2) would cause problems.
• You need instant, deterministic rollback — a single CLI command or button press.
• The deployment is time-sensitive (a hotfix) and you cannot afford a multi-hour canary process.

Canary is the right choice when:

• The change has uncertain production behaviour and you want to limit the blast radius.
• You want statistical confidence from real traffic before full promotion.
• The application can tolerate mixed versions simultaneously without inconsistency.