Zero Downtime Releases
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.
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 184.108.40.206 is in production. Please note the URL includes the name of the App Service.
The current Staging site is shown below. This currently represents the previous deployment which was Version 220.127.116.11. Please note the URL includes Staging as part of the App Service name.
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.
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.
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.
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.
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 18.104.22.168.
- We will make a change to the site and make a mistake. Version 22.214.171.124 will be deployed to staging.
- We will not notice our mistake and deploy version 126.96.36.199 to production by swapping slots.
- We will rollback version 188.8.131.52 by swapping slots again.
Version 184.108.40.206 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.
We make the following change to the site in Visual Studio.
The CI Build creates version 220.127.116.11.
Version 18.104.22.168 has been deployed to the staging slot. Production as awaiting an approval.
Note the URL shows the staging slot. The version is 22.214.171.124. We can also see the change we made. This is where all testing would be done before Production approval.
We approve the release into production. In this example, we do not notice the bug.
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.
The production ULR now points to the previous version.
Deployment Slots are a powerful feature of Azure and is well integrated with Visual Studio Team Services.
Next, we will discuss integration tests.
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 Hub. Contact me to set up a free meeting where we can dive deeply into the lab material and discuss your individual needs.