Azure Sites Slots
Posted : admin On 4/3/2022One of the premium features you get when using Azure Web Apps in a standard SKU is the deployment slots feature also known as staged deployment but it is actually more than that.
- Gets all available operations for the Microsoft.Web resource provider. Also exposes resource metric definitions Description for Gets all available operations for the Microsoft.Web resource provider. Also exposes resource metric definitions.
- Azure App Service brings together everything you need to create websites, mobile backends, and web APIs for any platform or device. Free and Shared (preview) plans provide different options to test your apps within your budget.
A deployment slot is a full Azure Web App and as one it has all the same configurations as any Azure Web App. When you swap deployment slots there are some settings you actually need to keep with the slot and not swap them. A setting that is not swapped is referred to as a setting that is sticky to the slot.
In this post I will go over the deployment slots concept and what you can do with it.
What are those deployment slots?
From a (standard) website you can create deployment slots which will actually be Azure Web App instances that are tied to that Website.
A deployment slot will carry the name of the Azure Web App + the name of the slot, for example:
If my Azure Web App is called mysite and I create a slot called staging then my slot will be an Azure Web App with the name mysite(staging) and its url will be http://mysite-staging.azurewebsites.net.
It's important to emphasize that the slot is in itself a regular Azure Web App, it will have its own app settings, connection string, any other configuration settings and even an scm site (https://mysite-staging.scm.azurewebsites.net).
In fact by default each Azure Web App has a single deployment slot called production which is the Azure Web App itself.
You can add more than one deployment slot.
Why do I need this?
The first feature of deployment slots is the Swap Slots and it's used for Staged Deployment
In short, the Swap operation will exchange the website's content between 2 deployment slots.
Later I'll explain what is swapped and what is not but note that swap is not about copying the content of the website but more about swapping DNS pointers.
So in our scenario we have the Production site with index.html that starts with Hello World and our staging slot has the same index.html but it starts with Yello World.
Before swap - http://mysite.azurewebsites.net/index.html will return Hello World...
After swap - http://mysite.azurewebsites.net/index.html will return Yello World...
Now to get this into a real life scenario.
Staged Deployment
Deploying your website in the traditional way, whether deploying via WebDeploy, FTP, git, CI or any other way, has weaknesses that may or may not concern you:
- After the deployment completes the website might restart and this results in a cold start for the website, the first request will be slower (can be significant depending on the website).
- Potentially you are deploying a 'bad' version of your website and maybe you would want to test it (in production) before releasing it to your customers.
This is where staged deployment comes into play. Instead of deploying directly to our production website we create a deployment slot used for staging and we deploy our new bits there.
Then we 'warm' our site (staging slot) by making requests to it and we can start testing our new bits verifying everything works as expected. Once we're ready we hit the Azure Portal's Swap button (or PowerShell/xplat cli command) and the slots will be swapped.
Our customers will not hit the 'cold start' delay and we have more confidence in our new bits.
Auto-Swap
Since we want to test our website before going into production we have this manual step where we hit the Swap button to swap.
But if we only want to address the 'cold start' delay we can configure the Auto Swap feature where the website automatically swaps a configured slot (in our case staging) with the Production slot after the deployment completes.
Currently auto-swap only works when deploying using WebDeploy (deploying through VS will usually use WebDeploy) and Continuous Integration (VSO, GitHub, Bitbucket). FTP and git push will not cause an auto swap.
Auto-swap can take a while to swap (1-2 minutes), until the swap completes any other attempts to deploy the website will fail.
To set this up you'll need to use the Azure PowerShell tool (download)
In PowerShell use the following command:
This command will set Azure Web Apps to auto swap the staging slot into Production slot whenever staging is deployed.
You can use the operation logs in the (current) Azure portal to see the auto swap operation status.
Deployment Slot App Settings / Connection String / Configuration
Azure Slot Machines
One important concept to understand about deployment slots is how the configuration works.
A deployment slot is a full Azure Web App and as one it has all the same configurations as any Azure Web App. When you swap deployment slots there are some settings you actually need to keep with the slot and not swap them.
A setting that is not swapped is referred to as a setting that is sticky to the slot.
Some of the default settings that are sticky to the slot:
- Most obvious one is the url - http://mysite-staging.azurewebsites.net/ will always point to the staging slot.
- WEBSITE_HOSTNAME environment variable for the staging slot will always be mysite-staging.azurewebsites.net and this is something we can use in our website code to find it's currently running in the Production slot or staging slot.
- Deployment settings - if you have the deployment profile for the staging slot, after a swap the profile would still point to the staging slot.
This also includes continuous integration settings - if you hooked your staging slot with a GitHub repository after a swap the hook will still exist between GitHub and the staging slot.
App settings and connection strings are not sticky to the slot and will remain with the website when swapped but we can configure selected app settings and connection strings to become sticky to the slot using a PowerShell command (not yet supported by the Azure portal).
Use this command in Azure PowerShell to set 2 app settings as sticky to the slot
And this command to set 2 connection strings as sticky to the slot
Sticky to the slot configuration is website-wide configuration and affects all slots in that website.
Deployment Slots Traffic Routing
Another great feature for deployment slots is the traffic routing also known as testing in production.
This feature will allow you to route traffic that is coming to your Azure Web App between your deployment slots based on percentage of the traffic.
This feature exists only in the new Azure preview portal.
In the portal under your website there is a tile called Testing in production, click on it to get to the 'Testing in production' blade where you can direct traffic coming to your website between all of your deployment slots.
One usage scenario for this feature is A/B testing.
By default 100% of the traffic will go to the Production slot but you can create a new deployment slot with a slightly different version of your website (differs by what you want to A/B test) and add it there with a 50% value so 50% of your visitors will actually be served from the new slot.
Another scenario for this feature is having a dev slot that is a little less stable which gets 1% of the traffic so you can test feature currently being developed with real traffic.
For more information on this feature.
Wrap Up
I hope that if the deployment slots were just a mysterious link/tile/concept before, you now know how to master them as they can bring lots of value to your production website.
I've got a lot of production web sites running in Azure right now. Some are for small side projects and some are larger like the sites for the Hanselminutes Podcast and This Developer's Life. I like Web Apps/Sites (which is Platform as a Service) rather than Virtual Machines (Infrastructure as a Service) because I don't like thinking about the underlying operating system if I can avoid it. I like to be able to scale the site up (faster, bigger) or out (more machines in the farm) with a slider bar.
In fact, there's some other more advanced and useful features that Azure Web Apps have that keep me using Web Apps almost exclusively.
I'll use a little site I made called KeysLeft.com that tells you how many keystrokes are left in your hands before you die. Think of it as a productivity awareness tool.
First, I'll add a Deployment Slot to my existing Git-deployed Web App. The source for KeysLeft lives in GitHub here. When I check-in a change it's automatically deployed. But what if I wanted to have a staging branch and automatically deploy to a staging.keysleft.com first? If it works out, then move it to production by swapping sites. That'd be sweet.
Azure Sites Slots Real Money
Staging Slots for Azure Web Apps
You can see here my main KeysLeft web app has a Staging 'side car' app that is totally separate but logically related/adjacent to production. Notice the 'swap' button in the toolbar. Love it.
This Web App has its configuration copied from the main one, and I can setup Continuous Deployment to pull from a different branch, like 'staging' for example. The name of the deployment slot becomes a suffix, so keysleft-staging.azurewebsites.net unless you set up a custom CNAME like staging.keysleft.com. You can have up to 4 deployment slots in addition to production (so dev, test, staging, whatever, production) on Standard Web Apps.
A/B Testing for Azure Web Apps
Once I've got a slot or two set up and running a version of my app, I can do A/B testing if I'd like. I can set up a feature that was called 'Testing in Production' and is now 'Traffic Routing' and tell Azure what percentage of traffic goes to prod and what goes to staging. Of course, you have to be sure to write your application so such that authentication and session is managed however is appropriate, especially if you'd like the user to have a seamless experience.
Here I've got 10% of the traffic going to staging, seamlessly, and the other 90% is going to production. I can make a small change (background color for example) and then hit the main site over and over and see the occasional (10% of course) request being routed to the staging slot. You can configure this static routing however you'd like.
Then I could hook up Application Insights or New Relic or some other event/diagnostics system and measure the difference in user reaction between features that changed.
Advanced Testing in Production
Made it this far? Then you're in for a treat. Static routing is cool, to be clear, but scripting a more dynamic experience is even more interesting. Galin Iliev, one of the developers of this feature, gave me this Powershell script to show off more powerful stuff.
First, you can use PowerShell to manage this stuff. You can change routing values and ramp up or ramp down. For example, here we start at 10% and change it by 5 every 10 minutes.
But! What if you could write code to actually make the decision to continue or fall back dynamically? You can add a callback URL and a Site Extension called the 'TiP Callback Extension.'
The Site Extension (and all Site Extensions for that matter) is just a little sidecar Web API. This callback gets a small POST when it's time to make a decision, and you decide what to do based on HTTP-related context that was passed in and then return a ChangeDirectionResult object as JSON. You can adjust traffic dynamically, you can adjust traffic when doing a deployment, do a slow, measured roll out, or back off if you detect issues.
NOTE: The ChangeDescisionCallbackUrl and this code below is totally optional (so don't stress) but it's super powerful. You can just do static routing, you can do basic scripted dynamic traffic routing, or you can have make a decision callback URL. So the choice is yours.
You can check out the code by visiting yoursite.scm.azurewebsites.net after installing the TiP callback site extension and look at the Site Extensions folder. That said, here is the general idea.
Here's the object you return. It's just a class with two ints, but this is super-annotated.
All this stuff is included in Standard Azure Web Apps so if you're using Standard apps (I have 19 websites running in my one Standard plan) then you already have this feature and it's included in the price. Pretty cool.
Related Links
- Video: Intro to Testing in Production
- Video: Scripting Testing in Production and Traffic Routing
- Video: Azure WebSites - Deployment Slots for Staging Sites
Sponsor: Big thanks to Infragistics for sponsoring the feed this week. Responsive web design on any browser, any platform and any device with Infragistics jQuery/HTML5 Controls. Get super-charged performance with the world’s fastest HTML5 Grid - Download for free now!
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.