This course covers the Design Azure Web and Mobile Apps part of the 70-534 exam, which is worth 5–10% of the exam. The intent of the course is to help fill in an knowledge gaps that you might have, and help to prepare you for the exam.
Welcome back. In this lesson, we'll be talking about deploying Azure hosted web apps.
This lesson is gonna be fun, because this is, at least to me, such an easy way to get a web app up and running. And with no real effort on our part, we get high availability, continuous delivery, and so much more.
So, in this lesson, we're gonna be talking about Azure site extensions, app service plans, deployment slots, publishing options, and more. So, we have a lot of great stuff to talk about.
Let's get started with site extensions. Now, site extensions are cool, because we get additional functionality for our web apps with the click of a button.
Site extensions are modules that allow us to extend the functionality of our web apps, typically for operational tasks, things such as monitoring, and we can enable them very easily, through the gallery of existing shared extensions.
We have quite a few to choose from. Let's select the app insights here, and then click okay to the license. And now that's about it. We click on the extension, and we can see more information about it, but it's installed and ready to use.
Okay, so, it may feel like site extensions really aren't a part of deploying apps, and you're right. However, it is part of the knowledge domain objective for the 7534, so that's why it's being covered here, even though it kind of feels like it's out of context.
The next thing that we're gonna cover is app service plans. In order to deploy a web app, you need to create or specify an existing app service plan. We talked about app service plans in a previous lesson.
An app service plan defines the supported feature set and capacity of a group of virtual machine resources. It also defines a pricing tier, such as free, shared, basic, and standard.
Each of these pricing tiers has subcategories that further define capabilities and capacity, such as disk space, number of applications, maximum instances, or available processor time.
An app service is unique to a specified region, resource group, and subscription. This means that two web apps can be in the same plan only if they're in the same region, resource group, and subscription.
There's not much else to say about app service plans, so let's move on to talk about deployment slots. A production deployment slot is automatically created when you create a new web app. It contains the content and configuration for your live web app. You can create up to four additional slots that hold their own independent content and configuration settings.
You can access the web apps running in these slots directly, meaning that you can test your web app before promoting it to production. You can swap any of the additional slots with the production slot, which swaps the content and some of the configuration settings with no down time.
Deployment slots are also useful for rollback scenarios, so, in the case of a bad deployment, you could simply swap the production slot with the slot that holds what was previously in production. This provides a rapid rollback strategy with minimal to no down time. An important note, when swapping slots, is that the content is swapped, not the configuration, or at least not all of it.
Configuration items that do come across include general settings, such as the .NET framework version, websockets, and always on, connection strings, handler mappings, app diagnostic settings, as well as monitoring settings.
Let's go ahead and create a deployment slot. We're gonna start out on the blade of our web app. And if you notice that the deployment slot option is disabled, that's because we need to change our app service plan.
So, let's change to a standard one. Okay, and now that that's enabled, we can click on the add button, and we're gonna create a new staging slot. And we'll use the configuration from the existing production. Now, once this is done, we're gonna have a completely independent version of the site.
Alright, great. It's done, and we can view the page. Notice that the URL has the name of the deployment slot in it. And it's showing the original HTML page that we get when we create a new web app, but before we've actually deployed anything of our own.
To better explain deployment slots, let's swap staging and production. Let's imagine that staging is exactly what we want to deploy. So, we click on swap. And, since we only have the two options, we have production and staging. We don't need to make any changes here.
We're gonna click okay, and then we're gonna give it a moment to do it's thing. Now, after it's done, we're gonna see that what we had in staging is now in production, and what was in production is now in staging. Okay. So, here we can see them, and there it is. Staging is production, production is now staging.
So, if we wanna swap them back, we can see that our production app is going to go back to our .NET web app that we created earlier in the course, and staging is gonna go back to that default HTML page. And there they each are. Now, I'm guessing I don't need to tell you how cool this is. Deployment slots also kind of segway into our next topic, which is deploying web apps.
So, we have multiple ways that we can actually deploy our web app. You've seen earlier, we used the Web Deploy method, and Web Deploy is a method to publish from a developer machine to an IIS based server and its integrated individual studio.
Now, we've been doing that throughout the course, so there shouldn't be anything surprising there. WebDeploy is based on a package. It's a zip file that just contains everything for our web app. We have some other options. FTP is a more generic and really rather old school way to publish a web app. Deployments can be done with any application supporting the FTP protocol.
Application is done through the deployment credentials. This is an okay option for a proof of concept. However, if you're gonna do anything substantial, I really recommend that you do something other than that, something that supports versioning like GIT or SVN. Now, if you wanna use those other methods, publishing to a deployment source is going to work well. It's a bit different from the other methods.
So, from the developer point of view, an application is uploaded to the deployment source, and it's not published directly to Azure. And then, whatever that source is that we sent our code to, it's going to trigger Azure to fetch the code.
We can use some of the most common source control services, such as Team Services, GitHub, BitBucket, et cetera. And we can also use internet drives, like Dropbox or OneDrive. These tend to be really good options for supporting continuous delivery, so that's a really cool feature.
Alright, in our next lesson, we're gonna talk about Azure hosted web apps for business continuity. So, if you're ready, then let's get started.
About the Author
Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.