-1

The rule-of-thumb/best practice which I only occasionally see challenged is that you should never commit environment-specific config files (e.g. .env, .ini, etc) to version control. The closest accepted practice I can find is that you may commit a default config file, but with the expectation that you manually edit the config on initial deployment.

However, in a DevOps role I'm not just writing app logic, I'm also automating the deployment of my code and its multiple environments. As a result, there's a specific need to keep track of what my configs look like so I may (re-)deploy my app if /when an environment needs to be recreated. For the same reason as with traditional code then, the most appealing solution is to store my config in the repo, but the question is what's the best and most scalable way to do so?

Obviously I'm not talking about storing any secrets in my config file. I'm also not against a solution that doesn't involve the repo. But I think discounting the repo outright is a bit silly and is a case of adhering to practice out of tradition more than its practical value.

How have others tackled this issue?

EDIT: Ideally, I think, there would be some extension for git that would allow env-specific configs to be associated with their app's repo, but would be segregated (stored in a separate repo?) in such a way as to avoid downloading an env's config when forking/branching a project. That seems well outside the scope of what's available though.

user3781737
  • 932
  • 7
  • 17

1 Answers1

1

There are two sets of approaches for this. One uses a configuration from a secret store, such as Vault, to store the configuration of your data independent of your repository and inject it through the environment. This lives outside of the repository entirely, but can be configured for different environments and ensures your data is securely encrypted.

The other, where you want to store some configuration in the repository, usually consists of storing the file in a separate directory as a sort of template and then copying it into place and editing it. The place it is used in production is typically ignored. You may choose to use a script for editing it or edit it by hand.

You can also store configuration in a separate, highly restricted repository, but that has all of the problems of checking secrets into a repository.

bk2204
  • 64,793
  • 6
  • 84
  • 100
  • If I'm understanding correctly, your 2nd suggestion is the defaults file I mentioned in my OP. However, as you also mentioned, that still involves me either editing it by hand, or using a script to edit it. For the former, I don't have any automation to redeploy an environment. For the latter, I would want to commit/store that script so I could use it to redeploy the environment, in which case I'm facing the original problem again. I'm looking into Vault after your first suggestion as well, but I'm not yet sure it's geared for storing per-environment configs. – user3781737 Jan 29 '21 at 17:51