Introduction & Overview
Creating an App Service Web App
Creating Web Service Containers
Configuring a Web App
The course is part of these learning pathsSee 2 more
You’ve got an idea for a great web app, or maybe you’ve already started building it. The next question is how are you going to get it out there on the Internet?
In this course, you will learn how you can quickly and easily set up a website and publish your app to the world with Azure App Service. Of course, web apps are a lot more complex and varied than just HTML pages and we will see how App Service supports a range of programming languages, frameworks, and even operating systems. We will explore features that greatly simplify application deployment and management, as well as those that will increase your app’s functionality like authentication and accessing on-premise data. App Service as with other Azure products has a raft of tools for monitoring and logging so you can make sure your app is performing optimally.
For any feedback, queries, or suggestions relating to this course, please contact us at email@example.com.
- Deploy apps using the Azure App Service
- Create a web app using the Azure Portal
- Create a web app using Visual Studio
- Understand the configuration and diagnostic capabilities available from Azure App Service
- Understand the advanced features of the service such as container deployment and deployment slots
This is a beginner level course suited developers or anyone wanting to know how to deploy web apps to the Azure cloud.
To get the most from this course, you should have a basic understanding of the software development lifecycle, while knowing how to code would be a plus.
Course source code
.NET 5.0 demo code
.NET Core 3.1 demo code
Creating a deployment slot is straightforward. Go to Deployment slots in your App Service app and click add slot. Give it a name and select whether or not you want to clone settings from your production slot and click the add button. You can see your new slot is the App Service name with hyphen slot name appended to it.
I’m going to add a new application setting called slot_name to this app. In the production version, I add the setting as normal with the value production. In the staging slot, I’ll add the same setting with the value staging but this time check Deployment slot setting. I’ll grab the publish profile for the staging slot and publish the app to the slot. As I flip between the production and staging URLs it’s picking up the different application settings.
The traffic % feature allows you to direct a specified proportion of requests to each of the slots, even though all requests are going to the production slot URL. I think is quite an ingenious idea, almost like having a double-blind testing scenario. You could test two user interfaces to see which one had the best stickiness or resulted in the most sales. Users don’t get to choose which version they go to but are randomly assigned. If we look at the domain cookies we can see one called TiPMix which stands for test in production mix, The value is the randomly generated number that determines which version of the website the user will get. When the value is less than 50 we go to the staging slot and greater than 50 we go to production. Below the TiPMix cookie, there is one called x-ms-routing-name. X-ms-routing-name can be appended to the production URL as a query string with a value of self or the staging slot name to go to either slot using just the production URL.
Let’s look at swapping slots to move the staging app into production. I’m just going to add some text to the home page to mimic a new version and deploy it to the staging slot. So, we can see that we have 2 different apps now. I’ll go to deployment slots and click swap. It’s telling us that our source is staging and the target is production. Clicking the swap button will trigger the process. Reloading the production URL shows us the new version, but crucially with the existing production application settings. Now, if we go to the staging URL, sure enough, we have our old production version. Of course, if something goes pear-shaped even after all the staging testing, it is easy and quick to do a rollback by re-swapping.
Hallam is a software architect with over 20 years experience across a wide range of industries. He began his software career as a Delphi/Interbase disciple but changed his allegiance to Microsoft with its deep and broad ecosystem. While Hallam has designed and crafted custom software utilizing web, mobile and desktop technologies, good quality reliable data is the key to a successful solution. The challenge of quickly turning data into useful information for digestion by humans and machines has led Hallam to specialize in database design and process automation. Showing customers how leverage new technology to change and improve their business processes is one of the key drivers keeping Hallam coming back to the keyboard.