Correct environments handling (appSettings.json)
We are using azure DevOps and I wondered what's the best way to handle environments.
Option 1: keep multiple app settings files for every environment and set on build the environment variable.
Option 2: use azure DevOps file replacement and use only one release configuration.
Both ways seems a bit weird. I want from one side to use the ASPNETCORE_ENVIRONMENT but also keep the variables in azure DevOps per environment and it seems they don't really work together.
Any suggestions what's the best way?
3 Replies
Use your AppSettings.json for your public constant values per-environment, that is fine and totally normal because then you can check it into version control.
Use the Configuration settings in Azure for handling all your Secrets, or better yet, just load 1 single value in there which is your key for loading in secrets from an even more secure secrets provider like a Hashicorp Vault instance or Azure Keyvault
Environment variables automatically get loaded into the default configuration of an aspnet core web app if they are prefixed with
DOTNET_ or ASPNETCORE_, and you can further add your own custom prefix for your app to load in env vars.
But I would just use Azure's Configuration page for your web app
So having for example:
* AppSettings.Json <- config values for all envs, "defaults" effectively
* AppSettings.Dev.Json
* AppSettings.QA.json
* AppSettings.Staging.json
* AppSettings.Production.json
Is totally fine and normal, just dont put secrets in there. I like to put the keys for my secrets in those json values but their values are all literally:
"SET VIA SECRETS" or something like thatSo how do you release for specific environment pipeline? If the only change is a public variable do you need to build again and create a PR with the change?
sure, if thats an issue because the value changes often, delegate that one out to be handled via Azure so you only need to reboot the app instead of redeploy it for changing the value.