First off, check out this great overview https://blogs.msdn.microsoft.com/devops/2017/04/05/managing-configuration-app-settings-for-multiple-environments-in-your-cd-pipeline/
And be aware of how stinky-easy this is when deploying to Azure web sites. Note: Creation of variables in Team Services, and slot settings in Azure are typically done by an Operations or Infrastructure/Deployment team, *not* by developers :).
- Managed via Variables in Team Services: https://www.visualstudio.com/en-us/docs/build/apps/cd/deploy-webdeploy-webapps#configure-the-environment
- Managed via Azure slot settings: https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-staged-publishing#configuration-for-deployment-slots
Here's a quick walkthrough, using a connection string value as an example.
- Create a variable in each environment with the name/value pair for the connection string. The "Name" must match the name of our connection string in web.config.
- Add the "Replace Tokens" task to the release. This will search all files with a .config extension and perform a match against any "names" that match an environment variable.
- In order to retain the ability to do easy debugging locally, keep the appropriate connection string setting in the web.config.
- Create "Debug" and "Release" configs that will tokenize the connection string when it is built by VSTS. In our case, it will replace the actual connectionstring value with "__DefaultConnectionString__" so that the replace tokens task from #2 will be able to find/replace it.
That's it! Debug locally using a local database (or whatever is appropriate), and have releases flow into the release pipeline where all other connection strings will be populated based on the environment in Team Services, or the slot setting in Azure.