Blue-Green Deployments with Octopus Deploy and Azure Websites from TFS

This article aim to explain how we can use Octopus Deploy to Automate Deployments to Azure Websites with a single deployment agent (tentacle) using the Blue-Green deployment pattern. This infrastructure is being used in my startup Grikly running purely on Azure using the BizSpark subscription, a simple and nice setup for a low cost software development company. The same concepts can be used in Enterprise grade systems.

Blue-Green deployments allow us to deploy web applications that require warm up time without any down times. This require running 2 instances of production grade environments such as a staging and production. We deploy to staging, have it warm up and swap it with production.

Octopus Deploy is a cool deployment tool that suites well in .NET projects.

TFS is an ALM suite which contains Source Control and Build Server. We’re currently utilizing Visual Studio Online.

Our workflow is that we will check in code to TFSGit, when we push it to VSO, the CI build will trigger. This builds the solution, versions and package up the components and ships them off to Octopus Deploy Server. We can then create releases, deploying them to Test and promoting them to Production.

Azure Configuration

On the Azure Websites, create a new deployment slot called “staging”. This feature can be found on the Dashboard of the website under quick glance;


When you have created the deployment slot, your website listing should look like the following:

Azure Website Listing

You may also have multiple deployment slots, as seen here, we have a slot for our testing environment.

Azure VM

We have installed Octopus Deploy on an Azure VM instance, and a tentacle on that same instance. Since we’re deploying applications to Azure Websites and not other VMs, there is no need for multiple deployment agents. Here are a few tips to remember when configuring the VM in Azure:

  1. Ensure Endpoint ports are exposed so we can remote and browse to the Deployment Server:Azure VM Endpoints
  2. Enable firewall inbound port 80.

TFS Configuration

Now that we have the Octopus Deployment Server and Agent running on the Virtual Machine, lets configure TFS and the visual studio project. Ensure to read those documentation and watch the videos provided. We do the following:

First install OctoPack NuGet package on the visual studio projects that will be deployed.

Then create or configure Continuous Integration build definition:TFS Build Settings

Remember to set Output location to AsConfigured.

There are a few commands we pass to the MSBuild arguments so we can package and deploy the OctoPack components.

/p:RunOctoPack=true /p:OctoPackPublishPackageToHttp=  /p:OctoPackPublishApiKey={mykey}

The Octopus Deploy Server comes with its own NuGet server, so we point our OctoPackPublishPackageToHttp to that server, since we configured our Octo Server to run on port 80, it will look sometime similar to the above.

Also in the screen shot above, we are running an UpdateVersion.ps1 script that versions our assembly before building.

Now push or check in your source and watch the build pushes the packages to the Octopus Deploy NuGet Server, check this by browsing to the Octopus Deploy web app and go to Library where there should be something like the following:

Octopus Deploy NuGet Packages

This now means everything is working great from TFS and Build, we can now move on to configuring deployments.

Octopus Deploy Server

Since we are only deploying Azure Websites, we only need 1 tentacle, our environment setup looks like the following screen shot:

Octopus Environment


We configured our local tentacle as a deployer role. The grikly-qa server you see there is for running automated UI Acceptance tests, which will be covered in another post.

We have a Website application that will be using Web Deploy for deploying to Azure. First the Step Template is required. Browse to Library -> Step Templates and follow the instructions there to copy the Web Deploy Step template from the community template list.

We can then create an application process similar to this screen shot:

Octopus ProcessWe’re doing a rolling deployment in the deployer role. Which means that we are running all child steps in sequence as Octopus by default tries to execute steps in parallel. Set the environments you want the steps to be executed in, such as Test and Production. The step named Swap Production with Staging is only executed in Production because that is the only environment the swap can take place.

Configuring the Grikly WebAPI step is nicely documented on the Octopus Deploy help site.

The Grikly WebAPI - Deploy step can be tokenized so we have different values being injected or replaced per deployment to a specific environment by using the Variables feature:

Octopus Deploy Variables

The Web Deploy Step can be configured as:

Octopus WebDeploy Config

Note, we tokenized the Publish Url and Website name with the variable name. This will be replaced based on the criteria specified in the scope of the variable.

Create and Execute a Release here manually to ensure this works and is deploying to the site successfully.

Blue-Green Azure Swapping

Now its time to implement swapping of staging and production.

Install and configure Azure Powershell on the Octopus Deploy server or the one with the tentacle that will be used as the deployer. My setup is using the Certificate method for authentication, so I downloaded and placed my certificate in a known location. The server may need to be restarted.

Execute this script on the VM where Azure Powershell was installed and manually verify that the websites were swapped

The core here is the method Switch-AzureWebsiteSlot which looks for the website named griklyapi and a slot staging and swapping it with the production slot. production is the default slot name given to the main website. The use of -Slot1 and -Slot2 parameters are here because we have multiple slots (testing and staging).

If this executes successfully, copy it into Step details for Swap Production with Staging process step.

Execute another release and deploy and watch the build gets deployed to staging and then automatically swapped to production. No downtime!