Future of VSTS Variables

[kamalsivalingam]

We have been using VSTS Variables heavily to store configuration for some of our microservices.
There is a huge limitation that when a configuration is incorrect, we would have to redeploy the microservice, since VSTS variables are tightly coupled with deployment.

We see a huge breakthrough with App Configuration. How do we manage configuration across different environments like QA/UAT/Production?

Also with App Configuration in place, what is the future of VSTS variables?

[yegu-ms]

Hi @kamalsivalingam,

Our App Configuration service is designed specifically for your scenario. There are a number of ways to set up multiple environments in our service. Using label is what we recommend. I can't comment on the future of VSTS variables. We always have customers who need something different. :)

[drago-draganov]

@kamalsivalingam,

While it's certainly possible to utilize Labels as deployment environment filter, keep in mind that the access to App Configuration is singular - access to the App Configuration assumes access to all key-value entries.
A good security practice is to limit the exposure (read/write) of production settings only to the parties that require such. One option is to utilize different App Configuration instances for production and dev/qa. Our Azure Portal and CLI can help managing such multi-instance setup.

[Yiming-Jia]

Hello @kamalsivalingam ,

We just published our VSTS extension, Azure App Configuration, in the VSTS marketplace. The extension is in preview mode now.

With the extension, you can add it into your build/release pipelines, and it will pull the configurations from your App Configuration and set as environment variables, which can be loaded later when you build/release your services.