Blue Green Deployment with Azure App Service Deployment Slots using Azure DevOps

In the ever-evolving world of software development, ensuring smooth deployments while minimizing downtime and risk is crucial. One effective strategy that has gained traction is Blue-Green Deployment. When in conjunction with Azure Web App’s Deployment Slots, this strategy can enhance your deployment process significantly. Let’s explore how to implement Blue-Green Deployment using Azure Web App’s Deployment Slots and how it can benefit your development lifecycle.

Why use Blue-Green Deployment?

• Minimal Downtime: The switch between environments can be almost instantaneous, minimising downtime for end-users.
• Reduced Risk: If issues are detected after the switch, rolling back to the blue environment is straightforward.
• Easy Rollback: Immediate rollback to the previous version if something goes wrong with the new deployment.

Azure Web App’s Deployment Slots using Azure DevOps

Azure Web App’s Deployment Slots are a built-in feature that supports Blue-Green Deployment. Deployment Slots enable you to host multiple versions of your application within a single Azure Web App, making it a perfect fit for Blue-Green Deployment.

Prerequisites:

• Your app must be running in the Standard, Premium, or Isolated tier.

Benefits of using deployment slots:

• Validate app changes in a staging slot before swapping with production.
• Warm up all instances of the slot before swapping to eliminate downtime.
• Seamless traffic redirection during swaps.
• Automate this workflow with auto swap.

Here’s how you can leverage Deployment Slots for Blue-Green Deployment:

1. Create Deployment Slots
2. Deploy to the Staging Slot
3. Validate the Staging Slot
4. Swap Slots
5. Monitor and Rollback if Needed

Let us look at how we can automate this using Azure DevOps. Consider an example of an API which returns a list of books. The API version 1 is live, and it returns a list of books with properties — id, name and isRead.

We need to deploy version 2 of this API which returns an additional field called ‘title’ in its response.

So, we deploy our updated code to a deployment slot rather than deploying it directly to the live web app.

We will look at specific steps to support Blue-Green Deployment on an existing Azure DevOps deployment pipeline. If you want to build a pipeline from scratch, you could refer to this step-by-step guide to using Azure Pipelines

1. Create Deployment Slots

Add an input Boolean parameter deployToSlot.

parameters:
- name: deployToSlot
  type: boolean
  default: false
- name: slotName
  type: string
  default: staging

Create a slot called ‘staging’ for example.

- task: AzurePowerShell@5
    displayName: "Create Slot"
    inputs:
      azureSubscription: $(azureSubscription)
      ScriptType: 'FilePath'
      ScriptPath: 'TodoApipipelinepowershellCreateAppSlot.ps1'
      ScriptArguments: '-resourceGroupName ${{ variables.resourceGroupName }} -appName ${{ variables.webAppName }} -slotName ${{ parameters.slotName }}'  
      azurePowerShellVersion: 'LatestVersion'
      workingDirectory: '$(Pipeline.Workspace)'

Below script is the core behind CreateAppSlot.ps1

New-AzWebAppSlot -ResourceGroupName $resourceGroupName -Name $webAppName -Slot $slotName

2. Deploy to the Staging Slot

Update the task to deploy latest code to the staging slot based on the deployToSlot parameter.

#deploy
- task: AzureRmWebAppDeployment@4
displayName: 'Azure App Service Deploy: webappname'
inputs:
ConnectionType: 'AzureRM'
azureSubscription: $(azureSubscription)
appType: webApp
WebAppName: $(webAppName)
ResourceGroupName: $(resourceGroupName)
Package: '$(build.artifactstagingdirectory)/**/*.zip'
${{ if eq(parameters.deployToSlot, true) }}:
deployToSlotOrASE: true
SlotName: ${{ parameters.slotName }}

And that forms the first part of the pipeline.

The deployment takes place on the staging slot.

We can see that the original instance of the webapp remains untouched. It has version 1 of the API.

But it has no version 2 yet.

You can refer to the staging slot in one of the following ways:

1. webappname-slotname

2. or by adding the query parameter x-ms-routing-name=slot-name

The version 2 API response contains the title field.

3. Validate the Staging Slot

You could add automated test scripts to the pipeline or carry out manual testing at the slot instance.

You could even set up release gates based on performance metrics or test results.

In this example, we have added a Manual intervention task to allow for manual testing.

4. Swap Slots

Once we have tested the slot instance, we can swap the slots for our changes to be applied to the production instance.

- task: AzureAppServiceManage@0
displayName: 'Swap Slot: ${{ parameters.slotName }}'
inputs:
azureSubscription: ${{ parameters.azureSubscription}}
action: 'Swap Slots'
WebAppName: ${{ parameters.webAppName}}
resourceGroupName: ${{ parameters.resourceGroupName }}
sourceSlot: ${{ parameters.slotName }}
preserveVnet: false

We swapped the slots and stopped the staging slot. The version 2 is now live.

and the staging slot is stopped.

Canary Deployments using Azure Web App Deployment Slots

Canary deployments are a strategy for releasing software updates gradually and progressively. The idea is to expose new code changes to a subset of users (the “canary group”) before rolling them out to everyone. This approach allows you to test the waters and gather insights without impacting all users at once.

Azure Web App Deployment Slots provide an excellent mechanism for implementing canary deployments. Here’s how you can set it up:

1. Create a Deployment Slot:

• Start by creating a deployment slot in your Azure App Service. This slot will serve as your staging environment.
• The main slot (usually called “production”) will continue to serve 100% of the traffic, while the newly created slot (let’s call it “staging”) will initially receive 0% of the traffic.

Let’s add an input Boolean parameter deployCanary to work in conjunction with deployToSlot parameter.

- name: deployCanary
  displayName: "Opt for Canary Deployment - set it to true"
  type: boolean
  default: false

2. Traffic Split:

• Configure the staging slot to receive 50% of incoming requests. This means that half of your users will see the new changes, while the other half will continue using the old version.
• Note that this approach uses a cookie-based redirection mechanism, which determines which slot serves traffic to each user.

Let’s add a manual intervention task before proceeding the traffic flow to staging slot.

Add a task to allow traffic to the staging slot.

- task: AzurePowerShell@5
    displayName: 'Add traffic routing to: ${{ parameters.slotName }}'
    inputs:
      azureSubscription: $(azureSubscription)
      ScriptType: 'FilePath'
      ScriptPath: 'TodoApipipelinepowershellAddRemoveAppTrafficRouting.ps1'
      ScriptArguments: '-resourceGroupName ${{ parameters.resourceGroupName }} -webAppName ${{ parameters.webAppName }} -slotName ${{ parameters.slotName }} -siteDomain ${{ parameters.siteDomain }} -changeIntervalInMinutes ${{ parameters.changeIntervalInMinutes }} -changeStep ${{ parameters.changeStep }} -maxReroutePercentage ${{ parameters.maxReroutePercentage}}'
      azurePowerShellVersion: 'LatestVersion'
      workingDirectory: '$(Pipeline.Workspace)'

Below script is at the core of AddRemoveAppTrafficRouting.ps1

Add-AzWebAppTrafficRouting -ResourceGroupName "$resourceGroupName" -WebAppName "$webAppName" -RoutingRule @{ActionHostName=$hostName;ReroutePercentage='50';ChangeIntervalInMinutes=$changeIntervalInMinutes;MinReroutePercentage='50';MaxReroutePercentage=90;ChangeStep=10;Name=$slotName;}

3. Testing and Insights:

• It gradually increases the percentage of traffic to the staging slot up to the set MaxReroutePercentage.
• Monitor user behavior, performance, and any issues that arise.
• If everything goes well, swap the slots and stop the staging slot.

4. Rollback:

• In case of issues, you can quickly roll back by adjusting the traffic split.
• The blast radius is limited to the canary group, minimising the impact on your entire user base.

Summary

Blue-Green Deployment using Azure Web App’s Deployment Slots offers a robust approach to managing deployments with minimal risk and downtime. By leveraging the power of deployment slots, you can streamline your deployment process, enhance application reliability, and improve the overall user experience. Embrace this strategy to keep your deployment practices efficient and resilient, paving the way for smoother and more reliable software updates.

If you want to learn more about the Microsoft Team here at Capgemini, take a look at our open roles and consider joining the team!

Blue Green Deployment with Azure App Service Deployment Slots using Azure DevOps was originally published in Capgemini Microsoft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Original Post https://medium.com/capgemini-microsoft-team/blue-green-deployment-with-azure-app-service-deployment-slots-using-azure-devops-f06583386178?source=rss—-333ebfdadb74—4