11

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.

Improve this question
7
  • Up for paid things ? Do you have any configuration management system ? what do you use to deploy ?
    – Tensibai
    Commented Mar 27, 2017 at 14:24
  • Paid options will be configured. Currently the settings are in TeamCity variables and deployment is via PowerShell scripts.
    – tim
    Commented Mar 27, 2017 at 14:28
  • Not strictly an answer, hence a comment - have you considered using Octopus Deploy for deployments as that allows you to manage Environmental Configuration in a highly flexible way.
    – Richard Slater
    Commented Mar 27, 2017 at 16:11
  • 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.
    – Jiri Klouda
    Commented Mar 27, 2017 at 16:21
  • recommend storing all configuration with source. we have multiple azure services and use the azure transformation syntax for all environment customizations. see 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.
    – No Refunds No Returns
    Commented Mar 27, 2017 at 21:08

2 Answers 2

Reset to default
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).

Improve this answer
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 (and prototypes/demos) on the topic over 5 years - including UIs for the toggling (if you need them).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.