Rollbacks in Azure Pipelines

Rollback strategies per service

The rollback mechanism depends on the Azure service being used. Each service has a different approach, and the speed and reliability of rollback varies:

App Service: slot swap rollback

When you deploy using slot swap (blue-green pattern), rollback is another slot swap in the opposite direction. The previous production version is still running in the staging slot, fully warmed up, ready to serve traffic. The swap-back takes seconds.

# Rollback: swap staging (old version) back to production
az webapp deployment slot swap \
  --name app-myapp-prod \
  --resource-group rg-prod \
  --slot staging \
  --target-slot production

# Verify rollback by checking the currently deployed commit or image
az webapp show \
  --name app-myapp-prod \
  --resource-group rg-prod \
  --query "siteConfig.linuxFxVersion"

If you did not use slots (deployed directly to production), rollback requires redeploying the previous artifact. This is slower and less reliable than slot-based rollback. This is one of the primary reasons to use deployment slots for all production deployments — not just for blue-green promotion, but for rollback capability.

Container Apps: revision traffic shift

Container Apps revisions are immutable — the previous version is still deployed and can receive traffic again with a single CLI command:

# List revisions to find the previous stable revision name
az containerapp revision list \
  --name myapp \
  --resource-group rg-prod \
  --query "[].{name:name, active:properties.active, traffic:properties.trafficWeight, created:properties.createdTime}" \
  --output table

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

# Deactivate the failed revision to stop it consuming resources
az containerapp revision deactivate \
  --name myapp \
  --resource-group rg-prod \
  --revision myapp--v2-failed

AKS: rollout undo and image revert

Kubernetes tracks the rollout history of Deployments. The kubectl rollout undo command reverts to the previous deployment revision, re-deploying the previous container image:

# Check rollout history to see available revisions
kubectl rollout history deployment/myapp -n production

# Rollback to the previous revision
kubectl rollout undo deployment/myapp -n production

# Rollback to a specific historical revision
kubectl rollout undo deployment/myapp -n production --to-revision=3

# Monitor the rollback progress
kubectl rollout status deployment/myapp -n production

# Verify the rolled-back image
kubectl get deployment myapp -n production \
  -o jsonpath='{.spec.template.spec.containers[0].image}'

By default, Kubernetes keeps 10 rollout history revisions. Configure spec.revisionHistoryLimit in your Deployment manifest if you need more or fewer historical revisions available for rollback.

Terraform: reverting infrastructure changes

Infrastructure rollback with Terraform is more complex than application rollback. Terraform applies the difference between the desired state (in code) and the current state (in the state file). To roll back, revert the Terraform code to the previous version and run terraform apply.

# Revert to the previous Terraform code version
git checkout HEAD~1 -- terraform/

# Review what will change before applying
terraform plan \
  -var-file=production.tfvars

# Apply the rollback (restores previous infrastructure state)
terraform apply \
  -var-file=production.tfvars \
  -auto-approve

Some Terraform resources cannot be rolled back cleanly. Deleting a database (because the new config removed it) loses data. Replacing a VM (because the image changed) may have a new IP. Before applying any Terraform rollback, run terraform plan and carefully review every resource marked for destruction or replacement.

Rollback stage in Azure Pipelines

Build the rollback path into the pipeline rather than improvising it during an incident. A dedicated rollback stage, gated by a manual approval, makes rollback a controlled, documented operation:

stages:
  - stage: Build
    jobs:
      - job: BuildApp
        steps:
          - task: DotNetCoreCLI@2
            inputs:
              command: publish
              arguments: '--output $(Build.ArtifactStagingDirectory)'
          - publish: $(Build.ArtifactStagingDirectory)
            artifact: drop

  - stage: DeployProd
    dependsOn: DeployStaging
    jobs:
      - deployment: Deploy
        environment: env-prod
        strategy:
          runOnce:
            deploy:
              steps:
                - task: AzureWebApp@1
                  inputs:
                    azureSubscription: 'sc-myapp-prod'
                    appName: 'app-myapp-prod'
                    deployToSlotOrASE: true
                    slotName: staging
                    package: '$(Pipeline.Workspace)/drop/**/*.zip'
                - task: AzureAppServiceManage@0
                  displayName: 'Swap staging to production'
                  inputs:
                    azureSubscription: 'sc-myapp-prod'
                    action: 'Swap Slots'
                    webAppName: 'app-myapp-prod'
                    sourceSlot: staging

  - stage: Rollback
    dependsOn: DeployProd
    # This stage only runs when triggered manually
    condition: false
    jobs:
      - deployment: RollbackProd
        environment: env-prod   # Manual approval gate on this environment
        strategy:
          runOnce:
            deploy:
              steps:
                - task: AzureAppServiceManage@0
                  displayName: 'Swap back: restore previous production version'
                  inputs:
                    azureSubscription: 'sc-myapp-prod'
                    action: 'Swap Slots'
                    webAppName: 'app-myapp-prod'
                    sourceSlot: staging

The rollback stage has condition: false so it never runs automatically. To trigger a rollback, navigate to the pipeline run in Azure DevOps, select “Stages,” and manually run the Rollback stage. The approval gate on env-prod requires a designated approver to sign off before the swap-back executes.

When you cannot roll back: database migrations

Database schema migrations are the most common reason a rollback becomes impossible or dangerous. If the new version runs a migration that drops a column, renames a table, or changes a data type in a way the old version cannot handle, rolling back the application code leaves the database in a state incompatible with the old code.

The only safe approach is to design migrations to be rollback-compatible:

Expand-contract pattern. Add the new column or table (expand phase), deploy the new application version that writes to both old and new schema, validate, then remove the old column or table (contract phase) in a separate, later deployment. The contract phase is only executed after the old application version is fully retired.

Never drop until you must. Adding columns or tables is safe and backwards-compatible. Removing columns removes data. Never remove a column in the same deployment as adding the new version that does not use it.

Feature flags for data model changes. If a new feature requires a schema change, deploy the schema change with the feature behind a flag. The old application version does not use the new column. The flag controls when the new code path (and the new column) are activated. Rollback is now just turning the flag off, not touching the schema.