In general all the settings files get deployed to all environments. At runtime the default builder will load the root appsettings.json file + the appsettings.<env>.json file based upon the DOTNET_ENVIRONMENT
and/or ASPNETCORE_ENVIRONMENT
environment variables as discussed here. Hence if you have defined either of these then it loads the environment-specific overload to update any env-specific stuff. For example if you define the envvar to be something
then it looks for a appsettings.something.json
file and applies it if found.
If you're targeting Azure App Services then the environment variable is set in your app service's Settings section. Set it there for each environment based upon what you want it to be (e.g. dev, staging, qa, production). If you are hosting on your own server then you have to set it using the control panel. Note that this is generally done at the system level.
If you, like me, don't like deploying env files for environments that aren't associated with it then add a step into your release pipeline (not the build pipeline you posted) to remove the files that shouldn't deploy. We have a deployment variable defined that identifiers the environment and we remove all files not related to that environment or the root.
If you are using deployment packages then it might already handle this for you if you can specify the environment. We don't really do to much with deployment packages so I cannot say for certain. Otherwise you'll need to clean up the file after it is deployed to the app service.