Blue-Green Deployments with Azure Web Apps

Blue-green deployment is a technique that reduces the downtime and risk of releasing new versions of an application by running two identical production environments called blue and green. At any time, only one of these environments is live, with the live environment serving all production traffic. For example, blue is currently live and green is idle. To release a new version, you deploy and test in the green environment . When you testing is completed you switch the routing so all incoming requests now go to green instead of blue. Green is now live, and blue is idle, now wash, rinse and repeat..

There are many benefits to adopting this technique – you can release to production as often as you like with zero-downtime and you can easily rollback your changes and swap from green to blue if needs be.

Azure Web Apps provides an out-of-the box solution for blue-green deployments through the use of deployment slots. When you provision a web application you can create up to 4 additional deployment slots. Deployment slots are actual live web apps with their own host names, you can push code to individual deployment slots and the content and configurations elements can be swapped through a simple API call. Azure manages all the traffic redirection when you swap your blue-green slots and guarantees that no requests are dropped during the swap.

Azure Resource Manager allows you define all the resources that make up your deployment environment in a single template file. Once defined, you can deploy, monitor and manage these resources as one atomic group.

By combining web apps, deployment slots and  azure resource manager it’s pretty easy to build  a continuous blue green deployment pipeline.

I’ve published a set of scripts and templates to enable blue-green deployments for a WebAPI backed by a azure SQL database, you can grab all the code here

https://github.com/aidancasey/azure-webapi-blue-green

BlueGreen

Create a new environment

Our stack consists of Web App and a SQL Azure database. these are defined in the file webapi-deploy.json.  All service specific settings are externalised and defined in a seperate paramters file. To create a brand new stack  invoke the New-AzureResourceGroupDeployment 

 

{
 "$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
 "contentVersion": "1.0.0.0",
 "parameters": {
 "siteName": {
 "value": "CustomerService"
 },
 "hostingPlanName": {
 "value": "NewServiceAppPlan"
 },
 "siteLocation": {
 "value": "North Europe"
 },
 "sku": {
 "value": "Standard"
 },
 "serverName": {
 "value": "mydatabaseserver"
 },
 "serverLocation": {
 "value": "North Europe"
 },
 "administratorLogin": {
 "value": "dbuser"
 },
 "administratorLoginPassword": {
 "value": "your-password"
 },
 "databaseName": {
 "value": "CustomerDatabase"
 }
 }
}

Once the web app has been created you can add a second deployment slot

function Add-StagingSlot([string]$sitename,[string]$location)
{
New-AzureWebsite -Name $sitename -Location $location -Slot "Stage"
}

Deploy to a staging slot and hot swap

The Publish-Azure-Website cmdlet lets you deploy a .NET webdeploy package to a named deployment slot on  you running Web App.  When you are ready to hot swap the blue and green enviornments call Switch-AzureWebsiteSlot

function Publish-Website([string]$name, [string]$package)
{
Switch-AzureMode AzureServiceManagement
Write-Host "publishing " + $name + "..."
Publish-AzureWebsiteProject -Name $name -Package $package
}

function Stage-Website([string]$name, [string]$package)
{
Switch-AzureMode AzureServiceManagement
Write-Host "publishing " + $name + "..."
Publish-AzureWebsiteProject -Name $name -Package $package -Slot "Stage"
}

function Swap-Website([string]$name)
{
Switch-AzureWebsiteSlot –Name $name -Force
}

A word on database changes

Handling database changes is the most complex part of a  blue-green deployment. the simplest approach is to have your blue and green applications share the same database. You need to ensure that all schema changes are backward compatible with both versions of the running application. The simplest way to run the database upgrade scripts is to bootstrap it to the Application_Start method in your WebApi project. FluentMigrator is a great open source tool which allows you to define your database schema changes in .NET code.

That’s, pretty much it, one last point about resource groups. When you are done with your stack and you’d like to tear everything down you can delete all the resources in your resource group by calling Remove-AzureResourceGroup

Useful Reading

Martin Fowler on Blue Green Deployments

Quickstart Resource Manager Templates

hope this helps !

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s