1

What's the best practice for maintaining app configuration for multiple test environments, (and production)?

At the moment I am keeping all the config in the code repo (a bitbucket server). Configs are text files in /config folders with subdirectories for each test environments (eg. config/SIT, config/UAT, config/PROD).

The problem is this seems very repetitive (non-DRY) and prone to human error.

Would maintaining the same config files using different git branches make more sense? Or are there any other tools or methods I should be looking at?

Improve this question
1
  • 2
    If you have a lot of duplicate things in your config files for different environments, then your config files contain too much. Try to split them up so the duplicate portion exists only once, and the environmental part becomes smaller.
    – Doc Brown
    Jan 10, 2020 at 11:10

2 Answers 2

Reset to default
3

In my view you should define separate execution environments in separate files, e.g. like Spring's application-test.yml, application-local.yml, application.yml etc. That way you can switch between executions by changing only one thing (the exact invokation command).

Whether or not to arrange the description files so that duplicate settings are declared only once is an independent question. I find this also worthwhile to do, either via a default/override mechanism (like Spring) or through explicit includes.

Improve this answer
1
  • Asp.net core has a similar mechanism except it's appsettings.json, appsettings.{EnvironmentName}.json. So you can switch the config based on a single environmental variable.
    – Blake
    Jan 10, 2020 at 12:37
2

You need to split the idea of a build and a deployment in your mind.

I find it best to imagine there is no internet and you are posting out CD ROMs to your customers, who then install and configure them

You Build the source code and burn the CD ROM with version X

Your customer Deploys the binary to their server and configures it for their environment.

By putting the config in source control (with the code) you are in effect burning it to the CD when you have no idea about how the customer will want to configure it.

Put the config in a separate Deployment script or scripts and you are stepping into the shoes of a customer who's just got your CD in the post.

You can then have a deployment script or variables per environment and run that multiple times against the same binary version of the software.

There are products on the market that can manage your deployment scripts such as Octopus deploy

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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