0

I'm looking for some advice for a way to effeciently store configurations of our applications. A place where we could store i.e. connection strings that we could use in web.config files or maybe even a way to store whole config files.

Maybe there is some kind of key value store solution that could help with that, when during build or after deployment using TFS/Jenkins we can point there and grab connection string that should be used in web.config.

My main point is to get rid of environment specific connetion strings kept in build/relase steps or scripts that are used after deployment. Just one organized place to rull them all.

Daveo
  • 169
  • 3
  • 11
  • What is wrong with the [_ConnectionStrings_](https://www.connectionstrings.com/store-connection-string-in-webconfig/) section of a web.config? – Steve Aug 12 '17 at 09:39
  • It's just about how and where it's value will be kept. When you got few applications each got dev, QA and staging environment editing it by hand or keeping those values in different scripts for each build/release definition is cumbersome. So I thought maybe it would be good idea to store i.e. connection strings for all environments in one place - maybe somekind of key value store solution or something similar : ) Thanks for response! – Daveo Aug 12 '17 at 10:38
  • Hi Daveo, have your tried Release Management in TFS? If my reply helped or gave a right direction. Appreciate for a vote or [mark it as an answer](https://meta.stackexchange.com/questions/5234/how-does-accepting-an-answer-work) which will also helps others in the community. – PatrickLu-MSFT Aug 17 '17 at 02:20

1 Answers1

0

There is a tool called Release Management in Team Foundation Server.

Each deployment to each environment may has different variables. This can be updated in a single place. In the release definition you can set up environment variables and set them per each environment. You could also have central replacements used in many applications.

  • Define a more generic deployment process once, and then customize it easily for each environment. For example, a variable can be used to represent the connection string for web deployment, and the value of this variable can be changed from one environment to another. These are custom variables.
  • Use information about the context of the particular release, environment, artifacts, or agent in which the deployment process is being run. For example, your script may need access to the
    location of the build to download it, or to the working directory on
    the agent to create temporary files. These are default variables.

Source Link: Variables in Release Management

For build you replace your dev condign data with tokens that RM then replaces per environment as part of the deployment. You could do this with a replace token task, it will replace any environment variables defined with the values set in the release variables, which you can edit via Configure variables:

enter image description here

For more details about how to use the variable, you could refer this blog: Using environment variables for configuration with VSTS build and release

Besides, Variable groups have been introduced in TFS/VSTS to address this need.

These are shared variables at the team project level, and can be used in build or release definitions. The ability to refer to variable groups from release definitions is complete and is now available in TFS 2017 and VSTS. The ability to refer to variables groups from build definitions is planned in the near feature.

PatrickLu-MSFT
  • 49,478
  • 5
  • 35
  • 62