This course will provide you with the practical knowledge and experience needed to master the Designing Web Apps section of the Architecting Microsoft Azure Solutions 70-534 certification exam. In addition to full coverage of all exam topics, this session will focus on the key competencies tested by the exam. We will start by creating a Web App, and we will discuss designing and deploying web apps for scalability and performance as well as the business continuity issues of Web App design.
Welcome back. In this lesson we'll be talking about deploying Azure hosted web apps. This lesson is going to 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. In this lesson, we're going to be talking about Azure site extensions, app service plans, deployment slots, publishing options and more. We have a lot of great stuff to talk about.
Let's get started with site extensions. 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. 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. It may feel like site extensions really aren't part of deploying apps and your right. However, it is part of the knowledge domain objective for the 7634, so that's why it's being covered here. Even though it kind of feels like it's out of context.
Next thing that we're going to 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 plan 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.
Let's move onto 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. 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 but 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, web sockets, 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 going to start out on the blade of our web app. If you notice that a deployment slot option is disabled, that's because we need to change our app service plan. So let's change to a standard one. Now that that's enabled, we can click on the add button and we're going to create a new staging slot. We'll use the configuration from the existing production. Now once this is done, we're going to 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. 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. 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 going to click okay and then we're going to give it a moment to do its thing. After it's done, we're going to see that what we had in staging is now in production and what was in production is now in staging. So here we can see them. There it is, staging is production, production is now staging. If we want to 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 going to go back to that default HTML page. There they each are. I'm guessing I don't need to tell you how cool this is.
Deployment slots also kind of segue into our next topic which is deploying web apps. We have multiple ways that we can actually deploy our web app. You've seen it earlier, we used the web deploy method. And web deploy is a method to publish from a developer machine to an IAS based server and its integrated individual studio. We've been doing that throughout the course. There shouldn't be anything surprising there. Web deploy 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 going to do anything substantial, I really recommend that you do something other than that. Something that supports versioning like Git or SVN.
If you want to use those other methods, publishing to a deployment source is going to work well. It's a bit different from the other methods. From the developer point of view, an application is uploaded to the deployment source and it's not published directly to Azure. 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, Git Hub, Bitbucket, etc. We can also use internet drives like Drop Box or One Drive. 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 Asure 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.