Modernising legacy applications is always a journey, and recently I tackled moving an existing WCF web service into Azure App Service. If you’ve worked with WCF, you’ll know the web.config file is the nerve centre, handling everything from parameters to connection strings.

But here’s the catch, this service needs to run in multiple environments (Development, Test, and Production) each with its own unique settings. That means multiple config files:

• Web.Dev.Config
• Web.Test.Config
• Web.Production.Config

The challenge

I didn’t want to build and maintain three separate web packages, one for each environment. That’s a recipe for drift and deployment headaches. Instead, I wanted a single build artifact that could be promoted through environments, swapping out only the environment-specific config as needed.

Enter web.config transformations. With these, you can:

• Keep a base web.config
• Layer on environment-specific transforms (Web.Dev.Config, etc.)

But when should the transformation happen? There are two main options, each with its own pros and cons:

1. At build time (using MSBuild):

   • The transformation is applied as part of the build process, so the output artifact already contains the environment-specific configuration.
   • This approach is simple if you only ever deploy to one environment per build, but it means you need to build a separate artifact for each environment. This breaks the principle of binary promotion, where the same artifact is promoted through Dev, Test, and Production. It also increases the risk of inconsistencies between builds.

2. At deployment (using the AzureRMWebAppDeployment@4 Azure DevOps Task):

   • The transformation is applied as part of the deployment process, allowing you to use a single, environment-agnostic build artifact and inject the correct configuration at deploy time.
   • This is the preferred approach for most modern pipelines, as it enables true binary promotion, reduces build times, and ensures that what you test is exactly what you deploy to production. It also aligns with best practices for repeatable, reliable deployments.

Solution: deploy-time transforms

Here’s how I set it up:

Build pipeline

# YAML
...

stages:
- stage: 'Build_Packages'
  jobs:
    - job: 'Build_WCFService'
      steps:

        - checkout: self
          fetchDepth: 0

        - task: VSBuild@1
          displayName: 'Build the WCF Service Solution'
          inputs:
            solution: '$(Build.SourcesDirectory)\*.sln'
            msbuildArgs: '/p:OutputPath=$(Build.ArtifactStagingDirectory)\WCFService /p:IsTransformWebConfigDisabled=true'
            platform: 'any cpu'
            vsVersion: 'latest'
            configuration: 'Release'
            clean: true

        - task: ArchiveFiles@2
          displayName: 'Archive WCF Service Build Output'
          inputs:
            rootFolderOrFile: '$(Build.ArtifactStagingDirectory)\WCFService\_PublishedWebsites\WCFService.Web'
            includeRootFolder: false
            archiveType: 'zip'
            archiveFile: '$(Build.ArtifactStagingDirectory)\WCFService\WCFService.zip'
            replaceExistingArchive: true

        - task: PublishPipelineArtifact@1
          displayName: 'Publish WCF Service Build Artifact'
          inputs:
            targetPath: '$(Build.ArtifactStagingDirectory)\WCFService\WCFService.zip'
            publishLocation: 'pipeline'
            artifactName: 'WCFService'

Release pipeline

Each environment (Dev, Test, Production) will get its own stage. The key is to ensure the correct environment name is set so the right transform is applied.

# YAML
...
- stage: 'Dev'
  displayName: 'Deploy to Dev Environment'
  variables:
  - group: 'Dev'
  dependsOn: 'Build_Packages'
  condition: succeeded()
  jobs:
    - deployment: Deploy_to_Dev
      environment: WCFServiceDev
      strategy:
        runOnce:
          deploy:
            steps:
              - template: EnvironmentDeploy.azurepipelinetemplate.yml
                parameters:
                  ARMConn: 'Dev'

- stage: 'Test'
  displayName: 'Deploy to Test Environment'
  variables:
  - group: 'Test'
  dependsOn: 'Dev'
  condition: succeeded()
  jobs:
    - deployment: Deploy_to_Test
      environment: WCFServiceTest
      strategy:
        runOnce:
          deploy:
            steps:
              - template: EnvironmentDeploy.azurepipelinetemplate.yml
                parameters:
                  ARMConn: 'Test'

- stage: 'Production'
  displayName: 'Deploy to Production Environment'
  variables:
  - group: 'Prod'
  dependsOn: 'Test'
  condition: succeeded()
  jobs:
    - deployment: Deploy_to_Production
      environment: WCFServiceProd
      strategy:
        runOnce:
          deploy:
            steps:
              - template: EnvironmentDeploy.azurepipelinetemplate.yml
                parameters:
                  ARMConn: 'Production'

Deployment template

#YAML

steps:

  - download: current
    displayName: 'Download the wcf Service Web package'
    artifact: WCFService

  ...

  - task: AzureRMWebAppDeployment@4
    displayName: 'Deploy WCF Service Web App'
    inputs:
      ConnectionType: 'AzureRM'
      azureSubscription: ${{ parameters.ARMConn }}
      appType: 'webApp'
      WebAppName: '$(armOutput.AppServiceName)'
      Package: '$(Pipeline.Workspace)/WCFService/WCFService.zip'
      enableXmlTransform: true

Here’s the bit that tripped me up: in multi-stage pipelines, the Release.EnvironmentName variable isn’t set by default. Without it, Azure DevOps doesn’t know which transform to apply. The fix? Explicitly set the variable in each stage:

# YAML
- stage: 'Dev'
  displayName: 'Deploy to Dev Environment'
  variables:
  ...
  - name: 'Release.EnvironmentName'
    value: 'Dev'
  ...

- stage: 'Test'
  displayName: 'Deploy to Test Environment'
  variables:
  ...
  - name: 'Release.EnvironmentName'
    value: 'Test'
  ...

- stage: 'Production'
  displayName: 'Deploy to Production Environment'
  variables:
  ...
  - name: 'Release.EnvironmentName'
    value: 'Production'
  ...

Troubleshooting and tips

Common pitfalls:

• Ensure your transform files (e.g., Web.Dev.config) are included in your build artifacts. If they’re missing, check your .csproj or project file to confirm they’re marked as Content and set to Copy to Output Directory if needed.
• File names are case-sensitive on some systems, double-check spelling and casing.
• If transforms aren’t being applied, verify that the Release.EnvironmentName variable is set correctly and matches your transform file naming.

Security note: Avoid storing secrets or sensitive values directly in your config files. Use Azure Key Vault or pipeline secrets for sensitive data, and reference them via environment variables or pipeline variables where possible.

Wrapping up

With this approach, you get a single, reusable build artifact and environment-specific configuration at deployment, no more juggling multiple packages. It’s a small change that makes your pipeline cleaner and your deployments more reliable.

Hope this helps, happy deploying!

Deploying updates to production environments demands both speed and control. Azure App Service deployment slots, combined with Azure DevOps pipelines, offer a powerful way to manage releases, enabling teams to validate changes in a live-like environment before they go public. However, ensuring that only reviewed and approved changes reach your users is critical for maintaining reliability and compliance.

Azure App Service Slots unlock powerful advantages:

• Site Review. Preview and test your site before it goes live, ensuring everything works as expected.
• Warmed-up Instances. Swap with confidence. Your instances are pre-warmed, so there’s no downtime, seamless traffic redirection, and zero dropped requests.
• Instant Rollback. If something goes wrong after a swap, simply swap back to restore your last known good version in seconds.

Best of all, deployment slots come at no extra cost. Check the Azure App Service limits to see how many slots your App Service Tier supports.

Automatic vs. Manual Slot Swaps

When it comes to swapping slots, there are two main approaches: automatic and manual.

• Automatic swaps are ideal when you want to quickly promote changes without a review, while still benefiting from pre-warmed instances and instant rollback.
• Manual swaps give you the opportunity to review and verify your site before it goes live, adding an extra layer of confidence.

But how do you keep a manual swap process governed and controlled? That’s where Azure DevOps pipelines and approvals come in.

In this article, you’ll learn how to set up a robust, approval-driven slot swap process in Azure DevOps.

Defining Azure Resources with Bicep

First, we need to define the resources needed in Azure. To do this I am going to use Infrastructure as Code (IaC). The template shown below creates the following resources:

• App Service Plan.
• App Service linked to the App Service Plan
  • Sub Resource that defines the App Service App Settings
• App Service Deployment Slot. Only created for Production environments - this is enforced through a conditional on the resource

Bicep Template: App Service and Deployment Slot

// Bicep

/**********************************
Bicep Template: App Service Deploy
Author: Andrew Wilson
***********************************/

targetScope = 'resourceGroup'

// ** Parameters **
// ****************

@description('Org Project Name')
param projectName string

@description('Application Name sitting within the project')
param applicationName string

@description('location name')
param location string = resourceGroup().location

@description('Environment name')
param env string = 'dev'

@description('App Service Plan sku name')
param appServicePlanSkuName string

@description('App Service Plan sku tier')
param appServicePlanSkuTier string

@description('Name of the deployment slot')
param deploymentSlotName string = 'staging'

// ** Variables **
// ***************

var appServicePlanName string = 'asp-${applicationName}-${env}-${location}'
var appServiceName string = 'app-${applicationName}-${env}-${location}'

// ** Resources **
// ***************

@description('Deploy an Azure App Service Plan')
resource AppServicePlan 'Microsoft.Web/serverfarms@2024-11-01' = {
  name: appServicePlanName
  location: location
  tags: {
    project: projectName
    application: applicationName
    environment: env
    version: deployment().properties.template.contentVersion
  }
  sku: {
    name: appServicePlanSkuName
    tier: appServicePlanSkuTier
  }
}

@description('Deploy an Azure App Service')
resource AppService 'Microsoft.Web/sites@2024-11-01' = {
  name: appServiceName
  location: location
  tags: {
    project: projectName
    application: applicationName
    environment: env
    version: deployment().properties.template.contentVersion
  }
  properties: {
    serverFarmId: AppServicePlan.id
    httpsOnly: true
  }
  resource AppServiceAppSettings 'config@2024-11-01' = {
    name: 'appsettings'
    properties: {
      ...
    }
  }  
}

@description('Deploy a deployment slot for the App Service')
resource deploymentSlot 'Microsoft.Web/sites/slots@2024-11-01' = if (env == 'prod') {
  name: deploymentSlotName
  parent: AppService
  location: location
  tags: {
    project: projectName
    application: applicationName
    environment: env
    version: deployment().properties.template.contentVersion
  }
  properties: { }
}

// ** Outputs **
// *************

@description('Outputs the App Service Name')
output appServiceName string = appServiceName

Important Note: Avoiding AutoSwap for Manual Swaps

Make sure that the DeploymentSlot resource does not have AutoSwap setup as this will counteract when Manual Swap is used. Such that the following process would be observed:

1. Deploy to Staging slot.
2. AutoSwap kicks in and swaps Staging with Production.
3. After Manual Approval, Slots are swapped again
4. You are now in the originating position with the new site still in Staging and Production with the old.

Designing the Azure DevOps Pipeline

Next we will setup our Azure DevOps Yaml pipeline. The pipeline’s goal is to orchestrate artifact building and environment deployments while adhering to DevOps best practices, such as binary promotion.

Pipeline Stages Explained

The pipeline has the following stages:

1. Build_Packages. Build a single set of artifacts that have been tested and versioned. (Best practice of Binary Promotion)

   The stage has two jobs to handle both Azure Bicep Templates and the App Service Web Package.

2. Development. Deploy to the Development Environment using an environment agnostic pipeline template*.

3. Staging. Deploy to the Staging Environment using an environment agnostic pipeline template*.

4. Production. Deploy to the Production Environment using an environment agnostic pipeline template*.

*The environment agnostic pipeline template is a reusable template for all environments.

Pipeline YAML: Build and Environment Deployments

# Yaml
# Orchestrating Template: Build And Environment Deployments

...

stages:
- stage: 'Build_Packages'
  jobs:
    - job: 'Test_Build_And_Version_Bicep_Templates'
      steps:

        ...

        - task: PublishPipelineArtifact@1
          displayName: 'Publish ARMOutput as template build artifact'
          inputs:
            targetPath: '$(Build.ArtifactStagingDirectory)/templates'
            publishLocation: 'pipeline'
            artifactName: 'ARMtemplates'

    - job: 'Build_and_Version_AppService'
      steps:

		...

        - task: PublishPipelineArtifact@1
          displayName: 'Publish App Service Build Artifact'
          inputs:
            targetPath: '$(Build.ArtifactStagingDirectory)/AppService.zip'
            publishLocation: 'pipeline'
            artifactName: 'AppService'


- stage: 'Development'
  displayName: 'Deploy to Dev Environment'
  ...
  jobs:
    - deployment: Deploy_to_Dev
      ...
            steps:
              - template: EnvironmentDeploy.azurepipelinetemplate.yml
                ...

- stage: 'Staging'
  displayName: 'Deploy to Staging Environment'
  ...
  jobs:
    - deployment: Deploy_to_Staging
      ...
            steps:
              - template: EnvironmentDeploy.azurepipelinetemplate.yml
                ...

- stage: 'Production'
  displayName: 'Deploy to Production Environment'
  ...
  jobs:
    - deployment: Deploy_to_Production
      ...
            steps:
              - template: EnvironmentDeploy.azurepipelinetemplate.yml
                ...

Once the Build_Packages stage has completed successfully, we now have two pipeline artifacts, ARMtemplates and AppService. In each environment deploy these two artifacts will be downloaded and used alongside environment specific Library Variable Groups to create specific environment deployments.

Environment-Agnostic Deployment Template

The environment agnostic template is shown below and has the following steps:

1. Artifact Downloads. Downloads the two pipeline artifacts, ARMtemplates and AppService.
2. Azure Resource Group Deployment. Using the built ARM template, specific environment library variable group and ARM Connection.
3. Custom PowerShell Script to Obtain Azure Deployment Outputs. Deployment output such as appServiceName will be created as job variables ready for future tasks to access.
4. Azure Web App Deploy (Specific for Dev and Staging). This task deploys straight to the production slot for non production environments.
5. Azure Web App Deploy (Specific for Prod). This task deploys to the staging slot ready for a manual slot swap.

Pipeline YAML Template: Reusable Environment-Agnostic Deployments

# Yaml
# Environment Deploy Template: Deploy Azure Resources and Obtain Outputs, Deploy App Service

steps:

  - download: current
    displayName: 'Download ARM templates'
    artifact: ARMtemplates

  - download: current
    displayName: 'Download the App Service Web package'
    artifact: AppService

  - task: AzureResourceManagerTemplateDeployment@3
    displayName: 'Deploy App Service ARM template'
    inputs:
      deploymentScope: 'Resource Group'
      azureResourceManagerConnection: ${{ parameters.ARMConn}}
      subscriptionId: '$(subscriptionId)'
      action: 'Create Or Update Resource Group'
      resourceGroupName: '$(resourceGroupName)'
      location: '$(location)'
      templateLocation: 'Linked artifact'
      csmFile: '$(Pipeline.Workspace)/ARMtemplates/AppService.azuredeploy.json'
      deploymentMode: 'Incremental'
      deploymentOutputs: deploymentOutputs
      overrideParameters: >-
        ...        

  - task: PowerShell@2
    name: armOutput
    displayName: 'Obtain Azure Deployment outputs'
    inputs:
      targetType: 'inline'
      script: |
        if (![string]::IsNullOrEmpty( '$(deploymentOutputs)' )) {
          $DeploymentOutputs = convertfrom-json '$(deploymentOutputs)'

          $DeploymentOutputs.PSObject.Properties | ForEach-Object {
              $keyname = $_.Name
              $value = $_.Value.value
              Write-Host "The value of [$keyName] is [$value]"
              Write-Host "##vso[task.setvariable variable=$keyname;isOutput=true]$value"
          }
        }        

  - task: AzureWebApp@1
    displayName: 'Deploy App Service - Dev and Staging Environment Only'
    condition: ne(variables['env'], 'prod')
    inputs:
      azureSubscription: ${{ parameters.ARMConn }}
      appType: 'webApp'
      appName: '$(armOutput.appServiceName)'
      package: '$(Pipeline.Workspace)/AppService/AppService.zip'

  - task: AzureWebApp@1
    displayName: 'Deploy App Service to Staging Slot - Prod Environment Only'
    condition: eq(variables['env'], 'prod')
    inputs:
      azureSubscription: ${{ parameters.ARMConn }}
      appType: 'webApp'
      appName: '$(armOutput.appServiceName)'
      deployToSlotOrASE: true
      resourceGroupName: '$(resourceGroupName)'
      slotName: '$(slotName)'
      package: '$(Pipeline.Workspace)/AppService/AppService.zip'

Accessing ARM Output Variables Across Jobs

Given that I will also need to access the appServiceName ARM Output that has been outputted from the armOutput task as a variable in future jobs, I have used the Output Variable for use in future jobs configuration.

Rather than job only:

##vso[task.setvariable variable=$keyname]$value

It uses the IsOutput so we can setup dependencies and access later:

##vso[task.setvariable variable=$keyname;isOutput=true]$value

Note: Accessing a Output Variable is different to a non-output variable:

Non-output Variable: '$(appServiceName)'

Output Variable: '$(armOutput.appServiceName)', you will need to reference the task name prior to the variable.

Manual Slot Swap with Azure DevOps Approvals

At this point, we now have our App Service resources deployed and the Site deployed to the production slots for Dev and Staging, and deployed to the Staging slot for Production.

But now down to the real question, how do I manually swap the slots using some Azure DevOps governance goodness?

To do this we are going to use the Azure DevOps Environment Approvals which will allow specific groups or users to approve the slot swap. Following this we will use the AzureAppServiceManage@0 task to conduct the slot swap.

Setting Up Azure DevOps Environments and Approvals

To setup an environment and approvals:

1. Sign in to your Azure DevOps organisation and open your project.
2. Select Pipelines > Environments > Create Environment.
3. Enter information for the environment, and then select Create. (For our purposes leave Resource as None)
4. In your Environment, Select Approvals and checks tab, and then select the + sign to add a new check.
5. Select Approvals, and then select Next.
6. Add users or groups as your designated Approvers, and if desired the following
   1. Instructions to approvers
   2. Allow approvers to approve their own runs
7. Make sure to Save.

Environments can be assigned to stages and jobs, but not to individual tasks. This means the slot swap task cannot reside within the environment-agnostic deployment template; it must be a separate, follow-on job.

To cater for the slot swap and environment approval, we are going to amend the orchestrating template to add another Job after the deployment Job in the Production deploy stage. This is shown below.

Adding the Slot Swap Job to the Pipeline

# Yaml
# Orchestrating Template: Build And Environment Deployments

...

- stage: 'Production'
  ...
  jobs:
    - deployment: Deploy_to_Production
      ...
            steps:
              - template: EnvironmentDeploy.azurepipelinetemplate.yml
                ...
    
    - deployment: Slot_Swap_to_Production
      dependsOn: Deploy_to_Production
      condition: succeeded()
      environment: ProductionEnv
      variables:
        appServiceName: $[ dependencies.Deploy_to_Production.outputs['Deploy_to_Production.armOutput.appServiceName'] ]
      strategy:
        runOnce:
          deploy:
            steps:
              - task: AzureAppServiceManage@0
                displayName: 'Swap App Service Staging Slot to Production'
                inputs:
                  azureSubscription: 'XXXYYYZZZ'
                  action: 'Swap Slots'
                  WebAppName: '$(appServiceName)'
                  ResourceGroupName: '$(resourceGroupName)'
                  SourceSlot: '$(slotName)'
                  SwapWithProduction: true

As can be seen in the amended template above, the Slot_Swap_to_Production job runs after the Deploy_to_Production job and expects it to have succeeded as a condition to running. The Slot_Swap_to_Production job also references the environment ProductionEnv for Approval prior to running.

Note: The first time the environment is used on the pipeline, the pipeline will ask for permission to use the resource.

Referencing Output Variables in the Slot Swap Job

The Azure App Service Manage task requires the WebAppName, which is set as an output variable in the environment-agnostic YAML pipeline template. To use this value in the Slot_Swap_to_Production job, define a new variable that references the output variable from the previous job. Once defined, you can use it within the current job as a standard variable (e.g., $(appServiceName)).

The variable reference uses the following syntax:

[dependencies.JobName.outputs[’JobName.TaskName.VariableName]]

You now have a pipeline that at the point of the slot swap job will wait for an appropriate approval prior to running and swapping your staging slot to production.

Summary

By combining Azure App Service deployment slots, Infrastructure as Code, and Azure DevOps environment approvals, you can create a robust, auditable deployment pipeline. This approach ensures that production releases are gated by manual approval, reducing risk and enabling rapid rollback if needed.

Ready to take your deployments to the next level? Try setting up manual slot swaps with approvals in your next release pipeline, and let your team experience stress-free, governed production launches.