Green/blue deployments on Azure with Octopus Deploy

Pushing the “promote to production” button should be fun, not scary. Implementing a blue/green deployment strategy is one way to alleviate the strees around pushing to prod.

Image borrowed from

Anyone who has ever deployed a piece of code to production, knows how nerve wracking the process can be. Sure, devops practices such as continuous integration and deployment have reduced the need for manual testing and 20 page installation manuals, but nevertheless: clicking that “Promote to production” button still has a tendency to prove Murphy’s law, and we are always looking for ways to reduce the risk even further.

Enter blue/green development. The principle is better explained elsewhere, but in short it is a way to promote a build to production and ensure it is working as expected in a production environment before exposing it to actual end users. I’ll stick to cloud foundry’s definition of blue/green in this article, meaning “blue” is the live production version and “green” is the new one.

More and more of my work is hosted on Azure these days, so setting up blue/green deployments for azure web sites has been a priority. Microsoft have already got the concept covered, with deployment slots, so it was just a matter of getting that to play nicely with Octopus Deploy, our go-to deployment server.

Since we are running quite a few web sites (and other sorts of resources), keeping the costs down was also a priority. That meant that I did not want all web sites to have a two deployment slots at all times (doubling the cost of each web site). Instead, I wanted the process to create the green (new) slot at the start of the process and remove it once the deployment was completed successfully. Octopus themselves have a guide for this, but I found it a bit lacking in detail, especially around the service principal/resource management parts. Hopefully, this guide will get you up and running without you having to fight through octopus’ less than informative error messages.

The process I had to set up, from source code change to live in production, was this.

  1. Get and build changes from source code repository.
  2. Run unit and integration tests
  3. Create green slot
  4. Deploy changes to green slot
  5. Warm up web site and run smoke tests
  6. Swap deployment slots (swap blue and green)
  7. Delete deployment slot created in pt 3.

Steps 1 and 2 are handled by our CI server, which pushes the build artifacts to Octopus’ nuget feed. Step 4 was already in place, so I needed to configure octopus to create the new slot, swap the new slot with current production, and delete it. In addition, I wanted to have a few rudimentary tests in place to verify the green slot before swapping it into the live production slot.

This is a screenshot of the complete build configuration, covering all the steps above:


A few words on Azure resources and powershell scripting

Octopus has a built in step template called “Run Azure powershell script” which is well suited for our purpose. However, since we need to create (and delete) resources via powershell the powershell scripts have to be run in the context of a user with the permissions to do so. In octopus, that means you have to have an azure connection/account configured as a service principal. Creating a service principal is a rather lengthy process, but the script at eases the process. I strongly urge you to change the password before running it.

Note that in order to get the resource manager cmdlets to work, I had to install the AzureRM module on the VM hosting octopus. That is done by starting powershell with administrator privileges and doing

Install-Module AzureRm

Creating the deployment slot

The first step of the deployment process is to create the green deployment slot. In the octopus process screen, click “Add step” and then “Run an Azure Powershell script”. Give the step a descriptive name (I chose “Create deployment slot”).

Under “Account”, you will have to select the service principal you created. If you have not added it to octopus already, now is the time: Select “Add new…” next to the Account drop down. The screenshot below indicates which fields you need to fill out (make sureyou check the “service principal” radio button first). The IDs (GUIDs) you need are all part of the output of the powershell script mentioned above.

Once the service principal is tested OK and saved, select it in the powershell script step configuration. Make sure the script source is set to “Source code” and paste the line below into the script text area (substituting the resource group name and web app name with the values applicable to your deployment):

New-AzureRmWebAppSlot -ResourceGroupName your-resource-group -Name web-app-name -Slot green

Leave the environment radio button on “run for all applicable environments”, and click “Save”.

Deploy the website to the green deployment slot

I will assume you already know how to set up the deploy to azure step. Make sure the step deploys to the green slot – in my case, the step config looks like this:

Deploy to azure octopus configuration. Note the “(cd)” part of the web app name. In this case, my green deployment slot in the web app stored in the “Azure.WebAppName” variable is called “cd”.

Test the new deployment

When the web app has been deployed (and assuming all went well), your app will now be available for testing on the deployment slot’s URL. E.g for a web app called my web app:

I am planning on running a selenium test suite against that URL, but for now I am merely verifying that the front page returns 200 OK. For that, I have set up a powershell step in octopus which runs the following script (with thanks to Steve Fenton). The web site in question is based on a CMS which in no way prides itself on a quick startup, hence the long waits and retries:

Write-Output "Starting"

$MaxAttempts = 10

If (![string]::IsNullOrWhiteSpace($TestUrl)) {
 Write-Output "Making request to $TestUrl"
 Try {
 $stopwatch = [Diagnostics.Stopwatch]::StartNew()
 # Allow redirections on the warm up
 $response = Invoke-WebRequest -UseBasicParsing $TestUrl -MaximumRedirection 10
 $statusCode = [int]$response.StatusCode
 Write-Output "$statusCode Warmed Up Site $TestUrl in $($stopwatch.ElapsedMilliseconds)s ms"
 } catch {
 $_.Exception|format-list -force
 For ($i = 0; $i -lt $MaxAttempts; $i++) {
 try {
 Write-Output "Checking Site"
 $stopwatch = [Diagnostics.Stopwatch]::StartNew()
 # Don't allow redirections on the check
 $response = Invoke-WebRequest -UseBasicParsing $TestUrl -MaximumRedirection 0
 $statusCode = [int]$response.StatusCode
 Write-Output "$statusCode Second request took $($stopwatch.ElapsedMilliseconds)s ms"
 If ($statusCode -ge 200 -And $statusCode -lt 400) {
 Start-Sleep -s 5
 } catch {
 $_.Exception|format-list -force

 If ($statusCode -ge 200 -And $statusCode -lt 400) {
 # Hooray, it worked
 } Else {
 throw "Warm up failed for " + $TestUrl
} Else {
 Write-Output "No TestUrl configured for this machine."

Write-Output "Done"

If and when this script returns successfully, it’s time to

Swap the green and blue slots

We have established that the green slot version is good to go. To promote it to the production slot, we need to swap the blue and green slots. This is done by another azure powershell octopus step (which should be run under a resource manager account), with the following script:

Switch-AzureWebsiteSlot –Name #{Azure.WebAppName} -Slot1 "green" -Force

This will cause the (already warmed up and tested) deployment in slot “cd” to be swapped with the current production version.

All that’s left now, is to clean up after ourselves:

Remove the green slot

The “green” slot is now redundant and can be removed. Yet another azure powershell step is needed:

Remove-AzureRmResource -ResourceGroupName  -ResourceType Microsoft.Web/sites/slots –Name #{Azure.WebAppName}/green -ApiVersion 2015-07-01 -Force

I have chosen to only run this step if all other steps succeed. YMMV, but I found that troubleshooting is much easier when the environment still exists.


Hopefully, this should have you up and running with green/blue deployments. There are certainly more thorough ways of doing this (ensuring that the front page loads is certainly not an exhaustive test of a new version), but this article will leave you with a process which can be extended to your liking. As briefly mentioned, I am working on a selenium test suite which I plan to plug into this project – I expect it to result in a blog post as well.

Leave a Reply

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

You are commenting using your 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 )

Connecting to %s