Ops / IT Pro
Please note: An updated version of this course is available here.
There's a lot of effort that goes into keeping our applications available, and secure. That's why so many cloud vendors offer platforms for hosting web-based applications. If you're building web apps, APIs, mobile backends, or business processes then you should consider looking into App Service! App Service has a lot of functionality. It meets compliance standards from around the world, it's highly scalable, it supports multiple languages and makes it easy to get your code deployed.
This Getting Started with Azure App Service course it's basically an intro, but for developers and IT Pros. In this course, you'll learn about the features of App Service at a high level as well as for each component. Then you'll learn about each of the 4 components of App Service through some demos. If you're a developer or IT Pro working with Azure, but new to App Service, this course is for you.
This course will help get you up-to-speed on App Service so that you can start developing / managing apps.
Getting Started With Azure App Service: What You'll Learn
|Lecture||What you'll learn|
|Course Intro||What to expect from this course|
|App Service Overview||A high-level overview of App Service|
|Web, Mobile, API App Overview||A high-level overview of Web, Mobile, API Apps|
|Logic App Overview||A high-level overview of Logic Apps|
|Mobile Apps: Easy Tables||How to use Easy Tables as a "no-code" option|
|Mobile Apps: Client||Running the client code from an iOS simulator|
|Mobile Apps: .NET Backend||Using a .NET backend|
|Mobile Apps: Auth||Using authentication with App Service|
|API Apps||Creating API Apps|
|Logic Apps||Automating business processes|
|Web Apps||Authentication and remote debugging|
|Deployments||Deployment slots and GitHub based deployments|
|Monitoring and Logging||Monitoring and logging options|
|Scaling||Scaling up and out|
|Next Steps||What's next|
Welcome back! In this lesson we’re going to talk about how to deploy App Service apps. We’re not going to cover release engineering, continuous integration, etcetera, however we will cover the different deployment mechanisms; in a future course we can cover deployment best practices, incorporating automated testing, etc.
Early in the course we covered the different components of Web, Mobile and API apps, so you should be familiar with what a deployment slot is, and what deployment options are available. However, it may not be obvious how to use these options.
By default, there’s always a deployment slot named production. Even if you don’t create any deployment slots, you’re still using the production slot. Now, deploying directly into production without a lot of automated testing is not a good idea. So, it’s recommended that you create a staging deployment slot.
Let’s jump into the portal to see how to create new deployment slots. Under the deployment section click on the Deployment Slots option, and when it loads, you can see the existing slots. In this case there aren’t any, so let’s add one for staging by clicking Add.
I’ll give it a name of staging, and under the configuration source there are two options, the first is to use the default deployment settings, which includes the default app. And the second option is to clone from an existing slot. In this case we could clone from production, however I want the difference between the apps to be obvious. So, let’s click ok and get this created. As you can see, it doesn’t take long to create it.
Once it’s done, if you click on it, you’ll notice the blade it opens up looks exactly like the blade for the web app . And that’s because a deployment slot is just another app deployed on the same underlying VMs. So it has all the same functionality.
If you look at the top of the page at the bread crumbs, you’ll see we’re in the staging deployment slot. On the overview tab take a look at the URL, it’s similar to the original, except it has the name of the deployment slot at the end of our app’s name. If we click on it, it loads up the default app that’s automatically deployed as a part of new apps created in the portal.
So now we have two independent versions of our Web App. If we go back to the default production deployment slot and click on that URL, It’s the web app demo from a previous lesson.
It’s worth noting that the amount of deployment slots is based on the Service Plan tier you’re using. Since the numbers are subject to change you’ll want to take note of how many deployment slots are available for your service plan. As of this recording, there are 5 allowed for the standard tier, and 20 for premium, and those numbers include the default production slot.
Okay, let’s swap staging and production to see how this works.
I’m on that staging slot’s overview page, and I’m going to swap its contents with production. At the top, if you click swap it’ll ask which slots you want to swap out.
There are two options for Swap type, you choose to swap, or swap with preview. Swapping with preview will allow you to swap the app settings and connection strings from the source to the destination to see how it would behave if you complete the swap. The idea is that you could swap the production app settings and connection strings to a staging slot and see if the code plays nicely with production data before deploying the code over.
For now, we’ll just swap things out without the preview.
The source is staging, and the destination is production, and there are no warnings. We’ll see what the warnings are all about in a moment.
For now, let’s swap these and then slightly fast forward. This process can take a moment, so don’t worry if it takes a minute.
Alright, now it’s done, let’s reload the pages, this is the staging URL, and now it contains the code that was in the production slot.
If we click on the tab that has the production URL, and reload, it has the staging app.
I mentioned app settings and connection strings previously, it’s common to use different values for certain settings or connection strings between environments. So let’s see how that works with deployment slots.
Let’s head into the Application Settings blade for the staging slot, and scroll down to the App settings and connection strings.
I’m going to add an App setting for a fake access token, and since this is the staging slot, I’ll call it staging value. Now the important part here is that this settings should only relate to this staging slot. So that’s what this Slot setting box does. It makes sure that whatever is in this field doesn’t get copied over when swapping.
And the same thing for connection strings, let’s add a fake connection string for a user database and set the slot setting. I also want to add another setting called CanSwap that isn’t bound to this slot...okay, perfect.
Now, let’s go to the production slot and add these same keys, with production specific values.
Let’s add the user db connection string first, because that’s the one I can remember, and with a value of “ProductionValue” and I’ll check the Slot setting box.
For the app setting...oh, right it was called AccessToken...and let’s give it a value of “ProductionValue” and select slot setting. Now let’s save this.
With this saved, let’s go back to the overview tab and swap these apps. The source is production, because that’s the slot I was on, and the destination is staging. Notice there’s a warning here, expanding it shows the warning, it’s because the staging slot has a setting that doesn’t exist in production, and it’s going to be transferred. Since we’re expecting this, it’s not a problem. So, let’s fire off this swap. Again, I’ll fast forward just bit...and there we go.
Now, let’s reload the staging URL...and it shows the staging app. And reloading production show production app.
If we look at the app settings for our production slot, you can see the production values are still there, however we now have this CanSwap setting that came from staging.
Let’s check out the values in the staging slot...we have the correct access token and db setting, and the CanSwap setting is gone. I’m going to include a link on the screen that will take you to the documentation and show which values will be swapped, and which won’t. I’d cover it here, but the documentation should be the canonical source for these sorts of things. It’s going to be a shortened URL, which means it is case sensitive. https://goo.gl/NOcU5T
So, this is a pretty cool feature, and one that when integrated into your release engineering process can allow for relatively simple rollbacks, assuming your database migrations are automated and support rollbacks.
Now that you understand deployment slots, let’s check out how to get your code deployed with the deployment options. Way back at the start of the course we looked at some of the different deployment options. So you know that there are different options. The option we’re going to test out now is the GitHub deployment.
You can see here that I have the web application demo in GitHub. It’s nothing special, it’s just a basic MVC app. So let’s get this configured such that when we make a commit, it’s deployed to App Service.
We’re here in the portal and this is the production slot. You can see that there’s a deployment options here...this is not the place we’re going to configure this. Now that doesn’t mean you can’t...it’s just to say that in most cases you don’t want to deploy from source code directly to production.
So, what we’re going to do is switch over to the staging slot. And now let’s select the Deployment Options, and select our source, which will be GitHub.
Notice that Azure knows who I am on Github, and that’s because I’ve configured this before. You’ll need to go through the OAuth dance if you haven’t previously done so.
First I need to select a project, which will be the top one here, the azure web app demo, option. The master branch is fine for this, however it’s worth noting that you can change it if you need to. And the performance test isn’t something we’re going to cover in this course, so let’s skip that.
It doesn’t take long to create, and then it notices that it’s never done a git pull, so it starts downloading the code from GitHub.
It takes a moment, and then builds the project, and deploys it. Now if we go back to the overview tab and view the app, you can see the basic MVC app. Let’s make a change to the code and commit it to see App Service pick up on the changes and build the project.
Let’s edit the home view. How about after ASP.NET we add the text “Amazing new change!’
And let’s save this, and I’m going to use GitHub Desktop to commit and push this change.
If we head back to the portal, and click on the deployment options for the staging slot, you can see it’s already picked up on the changes.
If we fast forward to once it’s built, and view the page...there’s our Amazing new change!
Looking at the URL for the production slot, notice that it’s the previous version. And that’s because we’ve only configured GitHub to deploy to the staging slot.
So now, if you’re happy with the changes on staging you could swap them into production. While we’re talking about swapping production slots, it’s worth mentioning that there is an option for Auto Swapping. Honestly, I’m not exactly sure how this would fit into a continuous delivery process, however I’ll show you the functionality, and let you determine if it’s useful to you. The intended value here is that auto-swapping pre-warms the app before it swaps it, avoiding a cold start.
From the staging slot, if we drill into Application Settings, and scroll down just a bit, there’s an option here for “Auto Swap” which will automatically swap slots with another of your choosing. In this example the only other option is production, so let’s use that. And let’s save this.
Now, if we head back to Visual Studio and change the text again this is going to get deployed to staging automatically, and then, it’ll get swapped to production. So let’s commit and push this change and then head back into the portal.
I’m going to fast forward because this could take a minute or two. Okay, I’ve waited for about 2 minutes, and now it’s time to reload the home page which should now show those changes.
And...there’s the updated content, and the staging site has the previous change.
This was a simple look at the functionality of deployment slots, swapping and source based deployments. However it should arm you with enough info to start figuring out how to integrate this with your release management process.
That’s going to wrap up this lesson. In the next lesson, we’ll cover monitoring and logging options for App Service. Alright, I’ll see you in the next lesson!
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.