3

There are two different ways how to manage the application settings if you use VSTS and Azure. Please keep in mind this is only an example of tools used for continuous deployment.

You can override JSON files(Web config in older systems) in the CD pipeline in VSTS or you can override the settings in Azure ‘Application Setting’ section. I’m just thinking what setting should be managed where? My idea is to manage settings which depend on 3rd party modules like databases (connection strings), external services (e.g. Application Insights) in the Azure Application Settings section. This can give you the flexibility to change some setting very quickly if some changes appear in the 3rd party system.

The stuff which depends only on the app I would manage in the VSTS. What about feature toggles? Let’s say you have a stock Market and you are building a module which manages selling/buying new cryptocurrency called Blah. After all the tests you decide to make a release of the feature and take of the flag which is responsible to enable/disable the new feature. Where would you take off the flag- in App Settings in Azure or in the CD pipeline in the VSTS?

Maybe there are more other types of settings which I didn’t mention, and which are problematic to manage? The main reason I am asking this question is the settings management becomes problematic when the application growths, it is very easy to cause a mess in the config files. Please tell me what is the proper way of management of the app settings in the Web Application?

GoldenAge
  • 2,918
  • 5
  • 25
  • 63
  • Have you resolved the issue by below answers? any update? – Andy Li-MSFT Sep 10 '18 at 07:33
  • I've found another interesting and very modern approach ARM https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-group-overview – GoldenAge Sep 10 '18 at 13:29
  • Well, if it works for you, you could post the solution as an answer and accept it. This can be beneficial to other community members reading this thread. – Andy Li-MSFT Sep 11 '18 at 09:08

3 Answers3

4

I found a very nice and modern alternatives for managing app settings: the Azure-Resource-Manager

The infrastructure for your application is typically made up of many components – maybe a virtual machine, storage account, and virtual network, or a web app, database, database server, and third-party services. You don't see these components as separate entities, instead you see them as related and interdependent parts of a single entity. You want to deploy, manage, and monitor them as a group. Azure Resource Manager enables you to work with the resources in your solution as a group. You can deploy, update, or delete all the resources for your solution in a single, coordinated operation. You use a template for deployment and that template can work for different environments such as testing, staging, and production. Resource Manager provides security, auditing, and tagging features to help you manage your resources after deployment.

Keep in mind that resources can be independent. I also found that Amazon created very similar thing called CloudFormation:

AWS CloudFormation provides a common language for you to describe and provision all the infrastructure resources in your cloud environment. CloudFormation allows you to use a simple text file to model and provision, in an automated and secure manner, all the resources needed for your applications across all regions and accounts. This file serves as the single source of truth for your cloud environment. AWS CloudFormation is available at no additional charge, and you pay only for the AWS resources needed to run your applications.

GoldenAge
  • 2,918
  • 5
  • 25
  • 63
2

The proper way as far as I'm concerned is to have a consistent approach. My personal preference (and I believe it is the preference of many others I've worked with) is to use the Application Settings within the App Service and therefore deploy those settings during a Release within the "Application and Configuration Settings" section of the deployment task.

Here are the benefits I see of using the App Settings during a release and not as part of the build:

  1. The settings are governed during release and the build artifact is therefore environment agnostic. This means you can deploy the same artifact to any environment by utilising the release settings. This is especially useful if you are deploying the same artifact to a disaster recovery environment where the settings differ.
  2. The app settings are in a consistent location. Anybody making changes to the settings will know where to look for them.
  3. You don't have to rebuild the artifact if you make a change to the core settings
Crwydryn
  • 840
  • 6
  • 13
1

You can try using the extension Azure WebApp Configuration task to manage the app settings in the Web Application.

The Azure WebApp Configuration task reads VSTS variables and adds those as AppSettings and ConnectionStrings to an Azure WebApp. The task also supports Slot Settings. The task can be linked to a web.config to validate if all AppSettings and ConnectionStrings in the web.config exists as VSTS variable.

You can also reference below articles to manage/configure the app settings:

Andy Li-MSFT
  • 28,712
  • 2
  • 33
  • 55