Azure Sites Slots

3/30/2022

The Essential Guide to Microsoft Teams End-User Engagement

During the swap operation the site in the staging slot is warmed up by making an HTTP request to its root directory. More detailed explanation of that process is available at How to warm up Azure Web App during deployment slots swap. By default the swap will proceed as long as the site responds with any status code. Azure Microsoft.Web/sites/slots/config JSON syntax and properties to use in Azure Resource Manager templates for deploying the resource. API version latest.

We take you through 10 best practices, considerations, and suggestions that can enrich your Microsoft Teams deployment and ensure both end-user adoption and engagement.

Deployment slots or Azure slots are actually instances of Azure Web Apps which are tied to that website. A deployment slot will carry the name of the Azure Web App + SlotName. For example, if my Azure Web App is called DebDemo and I create a slot called staging, then my slot will be an Azure Web App with the name DebDemo(staging) and its url. Azure Microsoft.Web/sites/slots JSON syntax and properties to use in Azure Resource Manager templates for deploying the resource. API version 2018-02-01.

Every Azure Website (recently renamed App Service) comes with a default deployment slot – production. Did you know that you can create up to 4 additional deployment slots to be used for dev, test, QA, or staging?
Deployment slots are actually live web apps with their own hostnames. Web app content and configurations elements can be swapped between two deployment slots. Benefits of deployment slots include:

You can validate web app changes in a staging deployment slot before swapping it with the production slot.
Deploying a web app to a slot first and swapping it into production ensures that all instances of the slot are warmed up before being swapped into production. This eliminates downtime when you deploy your web app. The traffic redirection is seamless, and no requests are dropped as a result of swap operations.
After a swap, the slot with previously staged web app now has the previous production web app. If the changes swapped into the production slot are not as you expected, you can perform the same swap immediately to get your “last known good site” back.

Stay tuned for more Azure Did You Know’s. Contact us at Perficient to have a certified Azure consultant help envision your solution today!

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.

Azure App Service Slot

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.

Azure Slot Machines

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.