Web App with custom Deployment slots This template provides an easy way to deploy a web app with custom deployment slots on Azure Web Apps. Is this page helpful? After the slot is created, if you click on the slot, you will be taken to another Web App. So what happens behind the scenes is Azure does create another Web App with some more sugar on top of it so that it can be classified as a deployment slot. You can use this slot to push code to this the same way you have pushed to the original Web App. The Web App deployment slots are a great feature, really useful however, they don't really work elegantly when the site is protected by an application gateway. The current behaviour means that the app gateway needs to be “aware” of the active deployment slot, this really isn't something that it should be aware of. It is possible to have a single production database shared by staging and production Azure App Service slots, and still having zero-downtime deployments. To do this, you need to ensure that all your migrations are backwards compatible, such that the current and new versions of the web app can run simultaneously with the same database.

1. Deployment Slots Azure Web
2. Azure Slot Machine Manual

The Essential Guide to Microsoft Teams End-User Engagement

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.

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!

Deployment Slots Azure Web

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.

Staging Slots for Azure Web Apps

Azure Slot Machine Manual

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.

AboutNewsletter