Zero Downtime Releases

Intro.png

We need to deploy Sports Store with zero down time. This is known as Blue / Green releases.

Our production infrastructure consists of two separate environments. The Live (Green) environment supports our end users. The Staging (Blue) environment is where we deploy an updated version. 

We perform any necessary testing on the Staging environment. When everything is OK, we swap IP addresses and the Staging Environment becomes the Live Environment. Azure App Services uses Deployment Slots to support this type of deployment.

Deployment Slots are an enhancement to App Services that add one or more environments, called slots to the default Production site. 

Azure Slots.png

The above example shows the production site which is named OcambSSBlueGreenWeb. There is one deployment slot named Staging.

The Production site is shown below. Version 1.3.0.6 is in production. Please note the URL includes the name of the App Service.

ProdSlot.png

The current Staging site is shown below. This currently represents the previous deployment which was Version 1.3.0.5. Please note the URL includes Staging as part of the App Service name.

stage slot.png

Deployment Slot Setup

A crucial point to make is that we are only using deployment slots for the Website. We are not deploying the database in this release pipeline. Databases add a whole other wrinkle to zero downtime deployments. This topic will be covered in a future article.

The release pipeline is shown below.

Pipeline.png

We use the artifacts created by the Sprint – Sports Store Lab build. These artifacts are consumed by the Staging environment and deployed to the Staging deployment slot.

When the release is deployed to Staging, all necessary testing is done using the Staging environment. The production environment may still be used by end users.

When testing is completed, we approve the Production release. This swaps the Staging with the Production slots using IP addresses. Now, production users have access to the new release.

The previous Production slot is now in the Staging slot. If something goes wrong in the new production release, we can roll back by swapping slots again.

App Service Deploy to Slot Setup

The task to deploy our website to the Staging Slot is shown below. We have highlighted the differences deployment slots require.

AppServiceTask.png

We specify that we want to deploy to a slot and we specify the slot we will deploy to. Other than this the App Service task is the same as any website deployment.

App Service Slot Swap

There is a task we use to swap slots. This is implemented in the pipeline as a separate environment named Production.

SwapTask.png

We set the Agent Phase to skip the download of artifacts. We do not need the artifacts since we are only swapping slots. The Swap Slot Task is shown below.

SWapTask2.png

We specify the source slot and that we want to swap with production.

Deployment Slot Example

We will now see deployment slots in action. We will use the following use case to demonstrate deployment slots.

  • Our current version of Sports Store is version 1.3.0.8. 
  • We will make a change to the site and make a mistake. Version 1.3.0.9 will be deployed to staging.
  • We will not notice our mistake and deploy version 1.3.0.9 to production by swapping slots.
  • We will rollback version 1.3.0.9 by swapping slots again.

Version 1.3.0.8 is shown below. Note we are using the production URL. We will be making changes to the Deployment Notes text to demonstrate how we change the site.

ProdSite.png

We make the following change to the site in Visual Studio. 

code changes.png

The CI Build creates version 1.3.0.9.

Build.png

Version 1.3.0.9 has been deployed to the staging slot. Production as awaiting an approval.

DeploymentExample.png

Note the URL shows the staging slot. The version is 1.3.0.9. We can also see the change we made. This is where all testing would be done before Production approval.

StageExample.png

We approve the release into production. In this example, we do not notice the bug.

ProdExampleError.png

We notice the mistake after we have deployed to production. We run the Rollback pipeline and approve the release. This swaps the Production slot with the Staging slot and rolls the site back to the previous version.

SWapExample.png

The production ULR now points to the previous version.

ProdFixed.png

Deployment Slots are a powerful feature of Azure and is well integrated with Visual Studio Team Services. 

Next, we will discuss integration tests.


Learn More

For details on the topics covered in this article, please visit the links below. You may also download the source code for the DevOps Roadmap Lab on Git HubContact me to set up a free meeting where we can dive deeply into the lab material  and discuss your individual needs.

  • Donovan Brown discusses deployment Slots on your DevOps pipeline here.
  • Martin Fowler has a good article about Blue / Green Deployment here.