Back when we all used Azure Cloud Services for running websites and backend worker tasks, we had the fabulous concept of deployment slots. Since January 2014, this concept was also introduced in the offering then called Azure Websites. Now, in Azure App Services Web Apps, the concept is still alive.
Basically, a deployment slot is another Web App that runs next to your original one. This means that you could create a deployment slot for your production environment and call that the pre-production slot, or staging slot, as in the illustration below:
At the time of this writing, you can create up to:
* 4 slots for Web Apps in the standard tier in addition to production
* 19 slots in the premium tier in addition to production
Note that a deployment slot is a fully fledged Web App, hosted in the same pricing tier as the Web App it is spawned from. Therefore it will incur costs.
Using a deployment slot can provide the following benefits:
* Test it in pre-production - you can deploy a pre-production version of your site and test it before it goes into production. You can do functional and automated testing on this, and also use it to do performance testing, to make sure that everything is alright without testing in production
* Easily deploy - once you are happy that your website in the staging slot works as expected, you can use the swap function (or even use Auto Swap) to get your version seamlessly in production.
* What happens here, is that the Virtual IP Address of the swap target (in my example the production slot) is re-pointed to the swap source (the staging slot) and vice versa.
* Also, before the swap happens, the website in the staging slot is pre-warmed to make sure that the website is ready to go when you swap it
* These mechanisms ensure that there is no downtime when you swap and makes for a great deployment mechanism
* Revert deployment - If for whatever reason, you’re not happy with the result of website now in production, you can easily revert back to the situation that was working before by swapping back to the staging slot
* You cannot use linked resource management in a non-production slot
* You cannot scale out a non-production slot (meaning that you cannot scale the number of instances)
Traffic Routing (previously called testing in production), can help you with doing A/B testing (actual testing in production).
You can set it up to route a percentage of all traffic to one or more deployment slots, as in the illustration below. By doing this, users are redirected to your deployment slot and they are testing in “production”.
Take advantage of deployment slots. It’s a simple enough mechanism to use with huge benefits. Try it out!
