Get an overview and use case for deployment slots for your Azure web app. Learn how to deploy and configure a deployment slot in the demonstration.
- [Instructor] Azure Deployment or staging slots allow you to update your Azure Web App with little to no downtime. Deployment slots provide a staging environment which are separate from your production environment. Each deployment slot contains an isolated live app with its own hostname. Deployment slots are only available in the standard and premium tiers. The standard tier allows for five slots, whereas the premium allows for 20. Using deployment slots have several benefits including validating the app changes before you release that app into production, warming up the slot before going live, and this will reduce downtime.
My favorite feature, you can always swap it back if required. Let's say there's a problem with the app itself. Let's go ahead and take a look at the deployment slots workflow. First of all, we have a production deployment slot and we have our app. We're going to go ahead and push that app, let's say from visual studio, to a staging slot. Once within that staging slot, we can perform some tests on it to make sure that that app is behaving as required. Next, we can go ahead and swap production and staging.
It is then available to our users. Now, let's take a look at the rollback workflow. Let's assume that we've already done the swap, and our users are using the app, and for some reason, something's not working correctly. We can swap them back. So we can flip back to the previous version, and then fix the error in the new version. Now you need to be aware of what settings are swapped when you do swap slots. All the general settings are swapped as are the app settings.
The connection strings and handle mappings are also swapped. The monitoring and diagnostic settings are swapped, and so are the WebJobs content. But just as important is knowing what is not swapped. The publishing endpoints will not be swapped. The custom domain names will not be swapped. Neither will the SSL certificates and bindings, or any of the scale settings that you have configured, as well as the WebJob schedulers.
Now available is Swap with preview, and when we use the Swap with preview, we can validate the behavior of the app before we actually swap it. Swap with preview with also prewarm the slot with the configuration, resulting in no downtime. We also have an Auto Swap feature. We use Auto Swap when we want to have continuous deployment, and when we use this feature, any new code that is pushed to the slot will automatically be swapped into the production slot.
Typically we see this a lot in DevOps scenarios. We also have a Custom Warm-Up feature, and when we use this feature, the customized initializations are implemented first, and then once those initializations are complete, and then those slots are swapped, reducing downtime. Then to use the Custom Warm-Up, you'll need to use the applicationInitialization configuration in web.config. Okay, let's go ahead and pop into a quick demo. Here, I'm already in Azure. I'm in a Resource group, and we're going to continue to work with our LIL WebApp.
I'm going to go ahead and open the blade for that. Under Deployment, you'll see that we have Deployment slot. I'm going to go ahead and click on that, and we don't have any slots already here, so I'm going to go ahead and add a slot. This is very simple. I'm going to call it staging. Then we have the option to either clone it from an existing slot, or we don't clone it at all. I'm just going to leave it blank for now and click OK. It'll take a few moments for the deployment slot to be created. Now our slot has been created and it's up and running.
At this point, I can easily go ahead and click Swap. Then we can select our Swap type, so we have our Swap or that Swap with preview that we were just talking about. Then, always kind of keep track of the Source and the Destination. So the Source in this case would be staging, and the Destination would be production if I was pushing content from staging to production. We can see we have a warning, and our warning is letting us know that some of the settings are not present in the Source, and that's because I don't have a true app set up here for our demonstration.
I'm going to go ahead and just close that. In your case, you wouldn't have any warnings, and you would just go ahead and click OK. I'm going to go ahead and close Swap. Yes, I know my edits will not be saved, that's okay. Now that our slot's been added, we can go ahead and configure auto swap. To do so, you'll open the blade for the slot that you just created, and you can do so by clicking on the name of that slot, and then scrolling down to Settings, and the click on Application settings.
If I continue to scroll down here, you'll notice that we have Auto Swap is disabled, and we have the Auto Swap Slot is set as production. You may be wondering where did production come from. That is the default name of your production slot. You can't name a slot production, it's already taken. That's all there is to it to configuring deployment slots for your Azure Web App. To quickly recap, deployment slot enabled you to upgrade your application with very little to no downtime.
Learn the intermediate-level skills needed to design Azure web and mobile apps for any organization, using the Azure Web Apps and Mobile Apps services. Instructor Sharon Bennett, a Microsoft Certified Solutions Expert, covers securing mobile and web apps with Azure Active Directory, creating WebJobs to script tasks such as queue processing and file maintenance, and extending mobile apps with custom code. Plus, learn how to update, back up, and restore your Azure apps.
As an intermediate-level course, an existing understanding of the Azure platform is required. After completing the training, IT professionals will also be better prepared for Azure certification.
- Create Azure web apps
- Create WebJobs
- Using Traffic Manager
- Adding a CDN to web apps
- Updating, backing up, and restoring Azure Web Apps
- Deploying Azure mobile apps