Answers: <p>There are many tools that can do something like this, including configuration management tools like Chef, Ansible, or Puppet; and KVS tools like Consul and etcd. You could also integrate it as a build step in your CI server, or sidestep the issue using live configuration at runtime against an external configuration store (again, something like Consul or etcd, or any database at all).</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-03-28T19:48:09.290Z
Answers: 2017-03-28T19:48:09.290Z
Answers: Adrian
Answers: <p>Possibly a different repo?  One with branches for QA, UAT, Prod (of nor more).  A repo that's different to your regular "Code as Code" and "Infrastructure as Code" repos. </p>
  
  <p>It is highly nuanced. How much config per env. Is it toggled between releases? Should those toggle states maintain state despite binary deploys. Which of client, customer, guest or user to you maintain config for?</p>
  
  <p>I wrote a bunch of <a href="http://paulhammant.com/categories.html#Configuration_as_Code" rel="nofollow noreferrer">blog entries</a> (and prototypes/demos) on the topic over 5 years - including UIs for the toggling (if you need them).</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-04-01T23:20:06.487Z
Answers: 2017-04-01T23:20:06.487Z
Answers: paul_h
Body: <p>I have a requirement to store configuration information on a per environment basis in a tool. </p>
  
  <p>This is a tool with a GUI for adding/updating configuration values (e.g connection strings). This should have a default value and be able to change this based on different environments.</p>
  
  <p>There should be an API to retrieve these configuration values during deployment to a particular environment to add to the application.</p>
  
  <p>I have searched for a while and can't see any tools that would fit this bill. Are there any suggestions?</p>
  
  <p><strong>Note</strong>: Currently the settings are in TeamCity variables and deployment is via PowerShell scripts.</p>
  
Comments: CC BY-SA 3.0
Comments: 2017-03-27T14:24:34.230Z
Comments: Up for paid things ? Do you have any configuration management system ? what do you use to deploy ?
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2017-03-27T14:28:20.553Z
Comments: Paid options will be configured. Currently the settings are in TeamCity variables and deployment is via PowerShell scripts.
Comments: tim
Comments: CC BY-SA 3.0
Comments: 2017-03-27T16:11:18.830Z
Comments: Not strictly an answer, hence a comment - have you considered using [Octopus Deploy](https://octopus.com/) for deployments as that allows you to manage Environmental Configuration in a highly flexible way.
Comments: Richard Slater
Comments: CC BY-SA 3.0
Comments: 2017-03-27T16:21:49.373Z
Comments: If you use sparse branch source control system, like ClearCase, you can simply branch the files with modifications, you can look at strategies for handling OSD (Operating System Dependent) changes in VCS. If you use git, you would need to keep rebasing the non-default branches constantly. Some  configuration tools have per environment settings through variables. In Ansible I have file with variable defaults and overlays for non-production environments. Don't store any settings in CI tools, they should be all in VCS. Including the TC configs.
Comments: Jiri Klouda
Comments: CC BY-SA 3.0
Comments: 2017-03-27T21:08:26.983Z
Comments: recommend storing all configuration with source.  we have multiple azure services and use the azure transformation syntax for all environment customizations.  see https://msdn.microsoft.com/en-us/library/dd465318(v=vs.100).aspx.  And we actually do this with powershell at deployment time as part of installation.  Depending on where you hook into the pipeline you can do this before putting bits on the box or, for passwords, after.  We use Azure Key Vault for secrets so they never appear in source control.
Comments: No Refunds No Returns
Comments: CC BY-SA 3.0
Comments: 2017-03-29T11:11:15.193Z
Comments: @RichardSlater - yes, Octopus was my recommendation, but the client says no.
Comments: tim
Comments: CC BY-SA 3.0
Comments: 2017-03-29T11:12:10.473Z
Comments: @tim that must be frustrating for you!
Comments: Richard Slater
Tags: <deployment><configuration-management><configuration><software-recommendation><casc>
Title: Tool for storing per environment configuration
UserDisplayName: tim
ThreadText: # Tool for storing per environment configuration
  
  (Asked by: username_0 on 2017-03-27)
  
  I have a requirement to store configuration information on a per environment basis in a tool.
  
  This is a tool with a GUI for adding/updating configuration values (e.g connection strings). This should have a default value and be able to change this based on different environments.
  
  There should be an API to retrieve these configuration values during deployment to a particular environment to add to the application.
  
  I have searched for a while and can't see any tools that would fit this bill. Are there any suggestions?
  
  **Note**: Currently the settings are in TeamCity variables and deployment is via PowerShell scripts.
  
  **Tags:** deployment, configuration-management, configuration, software-recommendation, casc
  
  > **Comments:**
  > **username_1**: Up for paid things ? Do you have any configuration management system ? what do you use to deploy ?  
  > **username_0**: Paid options will be configured. Currently the settings are in TeamCity variables and deployment is via PowerShell scripts.  
  > **username_2**: Not strictly an answer, hence a comment - have you considered using [Octopus Deploy](https://octopus.com/) for deployments as that allows you to manage Environmental Configuration in a highly flexible way.  
  > **username_3**: If you use sparse branch source control system, like ClearCase, you can simply branch the files with modifications, you can look at strategies for handling OSD (Operating System Dependent) changes in VCS. If you use git, you would need to keep rebasing the non-default branches constantly. Some  configuration tools have per environment settings through variables. In Ansible I have file with variable defaults and overlays for non-production environments. Don't store any settings in CI tools, they should be all in VCS. Including the TC configs.  
  > **username_4**: recommend storing all configuration with source.  we have multiple azure services and use the azure transformation syntax for all environment customizations.  see https://msdn.microsoft.com/en-us/library/dd465318(v=vs.100).aspx.  And we actually do this with powershell at deployment time as part of installation.  Depending on where you hook into the pipeline you can do this before putting bits on the box or, for passwords, after.  We use Azure Key Vault for secrets so they never appear in source control.  
  > **username_0**: @username_2 - yes, Octopus was my recommendation, but the client says no.  
  > **username_2**: @username_0 that must be frustrating for you!  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_5 on 2017-03-28. Score: 6
  
  There are many tools that can do something like this, including configuration management tools like Chef, Ansible, or Puppet; and KVS tools like Consul and etcd. You could also integrate it as a build step in your CI server, or sidestep the issue using live configuration at runtime against an external configuration store (again, something like Consul or etcd, or any database at all).
  
  
  ---
  
  ### Answer by username_6 on 2017-04-01. Score: 1
  
  Possibly a different repo? One with branches for QA, UAT, Prod (of nor more). A repo that's different to your regular "Code as Code" and "Infrastructure as Code" repos.
  
  It is highly nuanced. How much config per env. Is it toggled between releases? Should those toggle states maintain state despite binary deploys. Which of client, customer, guest or user to you maintain config for?
  
  I wrote a bunch of [blog entries](http://paulhammant.com/categories.html#Configuration_as_Code) (and prototypes/demos) on the topic over 5 years - including UIs for the toggling (if you need them).
  
  
  ---
  
  