Q: Define a plan for blue/green deployment with rollback on Azure using Terraform and pipelines.

Provision Azure App Service with a dedicated `staging` slot alongside `production`. Crucially, configure database connection strings and environment flags as `sticky_settings` so that when slots swap, configuration stays bound to the slot.

# Terraform App Service with Deployment Slot
resource "aws_app_service" "api" { ... }

resource "azurerm_app_service_slot" "green" {
  name                = "staging"
  app_service_name    = azurerm_linux_web_app.app.name
  resource_group_name = azurerm_resource_group.rg.name
  location            = azurerm_resource_group.rg.location
  app_service_plan_id = azurerm_service_plan.plan.id
}

resource "azurerm_linux_web_app_slot" "sticky_config" {
  # Mark slot-specific environment settings
}

The Azure DevOps pipeline packages the build artifact and deploys it exclusively to the Green (`staging`) slot. Execute automated smoke tests and verify warm-up health checks while Blue continues handling 100% of public traffic.

# Azure DevOps Pipeline Step
- task: AzureWebAppDeployment@4
  inputs:
    azureSubscription: 'Azure-OIDC'
    appName: 'app-prod-banking'
    deployToSlotOrASE: true
    slotName: 'staging'
    package: '$(Pipeline.Workspace)/**/*.zip'

Trigger an Azure slot swap. Azure manages the cutover seamlessly at the reverse-proxy routing layer by redirecting DNS/VIP bindings: Green becomes Production and Blue becomes Staging with zero dropped TCP connections.

- task: AzureAppServiceManage@0
  inputs:
    azureSubscription: 'Azure-OIDC'
    Action: 'Swap Slots'
    WebAppName: 'app-prod-banking'
    ResourceGroupName: 'rg-banking'
    SourceSlot: 'staging'
    SwapWithProduction: true

If post-swap telemetry reveals error spikes, trigger an immediate second slot swap. Because the previous stable Blue code is still alive in the staging slot, swapping back restores stability instantly without building or deploying.