What's the easiest way to deal with project configuration files?

user_206720 0
Viewed 19195

It's very common to have at least one configuration file in any project. Every time I share project with git, I have the same problem with:

  • sensitive information (each developer have different DB passwords etc)
  • task specific information (when developer works on certain task where one needs to change some settings)

Obviously, configs have to be ignored somehow to prevent developer specific data to flood main repository. Now there are several ways I used to use, each with some flaws:

  • .gitignore the config files
    • the most basic way
    • when developer clones repo, config file is missing and one has to find out where configs were recreate them
  • config file isn't ignored. It contains some dummy info and each developer either untracks and puts it to his .git/info/exclude or set git update-index --assume-unchanged ... to the file
    • files are available for anyone who clones repo
    • it contains advanced techniques which could confuse people that work with git for the first time
    • when someone commits config files by accident, it won't allow people to pull/fetch (as excludes don't work the same way as .gitignore)
  • distribute config files suffixed with, for example, _original while having the real files in .gitignore. Each developer then renames files to real names
    • files are available for anyone who clones repo
    • one has to search for all configs throughout application and rename them

Are there any other, possibly, better ways to handle this? I suspect I'm missing something, some plugin at least.

git
10 Answers

A lot of good options listed. A few more options to mention:

  • Add all configs to .gitignore. Then have a separate git project, with the just the configuration files. (Keep this GIT #2 in a totally different folder.) In this GIT #2, make a few scripts similar to apply-config /path/to/my_git1, save-config /path/to/my_git1 which copy in, or save configuration files for the main GIT repo.
    • I prefer this to using submodules. I've found working with submodules cumbersome across a large team.
    • You can then track configurations, or use multiple GIT repos for things like production settings, debug settings, more optimized settings, etc.
    • Uses one tool (GIT) that everyone understands.
  • I like the idea of looking in the home folder for sensitive things like DB connection info. (Mentioned by @avh)
  • For devOps, you may want to consider things like Ansible / Salt / Chef / Puppet for automating deployments and settings.
user_10865840
Related