Common mistakes to avoid when deploying to Azure Web App

By Dara Oladapo, DevOps and Cloud Engineer

28/03/2023

If you are looking for a fast and uncomplicated way to host your web application on the cloud, you might want to consider Azure Web App. Azure Web App is a service that allows you to run web apps on Azure without having to manage servers, virtual machines, or containers – you can simply upload your code, configure your settings, and let Azure handle the rest. However, as with any cloud service, there are some potential pitfalls that you need to be aware of when deploying to Azure Web App.

In this blog post, we will share some of the common mistakes that we have seen developers make when deploying to Azure Web App, and how to avoid them. We will also cover topics such as deployment methods, app settings, and connection strings. By following these tips, you can avoid some of the common headaches that can occur when deploying to Azure Web App and enjoy the benefits of this powerful and convenient service.

Let us look at these common mistakes under five sub-topics.

Operating System and Runtimes

One of the best things about Azure Web App is its support for multiple frameworks and runtimes including .NET, Java, Ruby, JavaScript, PHP, and Python. For those who still develop on the .NET Framework, a common mistake that is made when provisioning Azure Web App is to create a Linux based web application. This would cause an issue because the application would need Windows specific libraries and dependencies to run successfully. So, when deploying, ensure you pick the correct operating system and runtime for your web application.

There are two operating system options to pick from when creating an Azure Web App – Windows and Linux. While you can deploy most of your applications on either operating system, check your runtime and framework compatibility – especially if you are running a .NET Framework based application.

For more on operating systems in Azure web app, check out this article on Operating System Functionality.

App Settings and Environment Variables

Another common mistake I see developers make when deploying applications is that they forget to update their application settings from local values to cloud-based values. Let me explain more.

Let us take an example, where you are loading a .csv file to read in your application to seed data. Most times, this would be done from a local disk file and put in the appsetting.json/web.config file (if you are writing .NET). Sometimes, developers will forget to update this value to a cloud based one – for example, the same .csv file but in Azure Storage or in some other cloud storage solution, and the application will keep failing to load.

If possible, your local app settings, environment variables or configuration should not be committed or deployed alongside your code. Rather, app settings and environment variables for your deployment applications should be configured on the application, deployed to the web app as part of your CICD process, or put in an app configuration/secret store like Azure Key Vault.

Connection Strings

Another common mistake, and a follow-on from the previous one, is connection strings. Most times when developing locally, a developer would connect to a local data store. For example this might be Microsoft SQL Server on localhost, and the database connection strong would look something like this:

“ConnectionStrings”: {
“DefaultConnection”: “Server=.;Database=DaraDB;Trusted_Connection=True;MultipleActiveResultSets=true”
}

But when deployed – especially through the “Right-Click-Deploy” method, developers often forget to set the connection string values in the Azure Portal which could sometimes lead to hours of pointless troubleshooting.

To avoid this, it is always recommended – if you are sticking to right-click-deploy – to modify the database connection string to the one accessible by your Azure Web App on the deployment configuration page.

Looking below, we see that Visual Studio has detected a service connection to a database and suggests we add it to our web application in Azure.

When you click on the “+” button, you get a prompt to add various services. You will then need to select Azure SQL database.

After selecting your database, you are prompted to input the login details and preferred location to save the connection string values.

Now this saves post-deployment stress.

If you’re using Azure SQL database, you would need to “Allow Azure services” access to the database server’s firewall, or set up a virtual network to allow a private connection in-between the two services.

Local File Storage

When debugging applications locally, sometimes we need to upload resources like images, documents, audio and video files. Some coding conventions – for example in .NET using File.MapPath(localFilePath.ext) – put these resources in the source code folder. These often get committed and deployed alongside the application code to Azure Web App, which normally should not be. This starts to fill up the web app allocated storage quota, and can sometimes lead to a lack of storage space and may hinder such an application from performing optimally.

What can be done in this case is to employ a storage solution like Azure Blob Storage even during local development, and ensure that any file loaded into memory is deleted after being successfully uploaded.

The question might then get asked, “would I not be incurring costs in the cloud?” The answer to that is that when developing locally, you can use the Azurite emulator to upload and work with files as if you were connecting to a cloud resource.

Database Migrations

One of the most common mistakes with deploying and using Azure web applications is that often, when developers add migrations to their applications, they apply them normally, upgrade the database and run the application. When things look good, they go ahead and deploy as-is. But once the application gets loaded, it fails to start-up because it is trying to connect to a database with outdated migrations. There are two ways you can fix this mistake: