Operating System Functionality<\/a>. <\/p>\n\n\n\nApp Settings and Environment Variables <\/h3>\n\n\n\n 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. <\/p>\n\n\n\n
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 \u2013 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. <\/p>\n\n\n\n
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. <\/p>\n\n\n\n
Connection Strings <\/h3>\n\n\n\n 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:<\/p>\n\n\n
“ConnectionStrings”: {<\/span> <\/span> “DefaultConnection”: “Server=.;Database=DaraDB;Trusted_Connection=True;MultipleActiveResultSets=true”<\/span> }<\/span> <\/span><\/p>\n\n\nBut when deployed \u2013 especially through the \u201cRight-Click-Deploy\u201d method, developers often forget to set the connection string values in the Azure Portal which could sometimes lead to hours of pointless troubleshooting. <\/p>\n\n\n\n
To avoid this, it is always recommended \u2013 if you are sticking to right-click-deploy \u2013 to modify the database connection string to the one accessible by your Azure Web App on the deployment configuration page. <\/p>\n\n\n <\/figure>\n\n\n\nLooking 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. <\/p>\n\n\n\n
When you click on the \u201c+\u201d button, you get a prompt to add various services. You will then need to select Azure SQL database. <\/p>\n\n\n <\/figure>\n\n\n\nAfter selecting your database, you are prompted to input the login details and preferred location to save the connection string values. <\/p>\n\n\n <\/figure>\n\n\n\nNow this saves post-deployment stress. <\/p>\n\n\n <\/figure>\n\n\n <\/figure>\n\n\n\nIf you’re using Azure SQL database, you would need to \u201cAllow Azure services\u201d access to the database server\u2019s firewall, or set up a virtual network to allow a private connection in-between the two services. <\/p>\n\n\n <\/figure>\n\n\n\nLocal File Storage <\/h3>\n\n\n\n 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)<\/strong> – 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. <\/p>\n\n\n\nWhat 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. <\/p>\n\n\n\n
The question might then get asked, \u201cwould I not be incurring costs in the cloud?\u201d The answer to that is that when developing locally, you can use the Azurite emulator<\/a> to upload and work with files as if you were connecting to a cloud resource. <\/p>\n\n\n\nDatabase Migrations <\/h3>\n\n\n\n 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: <\/p>\n\n\n\n
\nEmploy automatic database migrations once your application starts up. <\/li>\n\n\n\n Run database migrations as part of the CICD process. <\/li>\n<\/ul>\n\n\n\nWe have looked at 5 of the common mistakes made when deploying applications to Azure web apps and possible ways to avoid them. Happy deployments! <\/p>\n","protected":false},"excerpt":{"rendered":"
In this blog post we share some of the common mistakes that we see developers make when deploying to Azure Web App.<\/p>\n","protected":false},"author":430,"featured_media":21801,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ep_exclude_from_search":false,"_classifai_error":"","_classifai_text_to_speech_error":"","footnotes":""},"categories":[594],"post_tag":[128,519],"content-type":[],"coauthors":[2028],"class_list":["post-67042","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technetuk","tag-azure","tag-technet-uk"],"yoast_head":"\n
Common mistakes to avoid when deploying to Azure Web App - Microsoft Industry Blogs - United Kingdom<\/title>\n \n \n \n \n \n \n \n \n \n \n \n\t \n\t \n\t \n \n \n \n\t \n\t \n\t \n