Managing config files in Version Control – an idea for a gem

http://stackoverflow.com/questions/1449836/how-to-manage-rails-database-yml

First, move database.yml to a template file.

If you’re on Git:

git mv config/database.yml config/database.yml.example
git commit -m "moved database.yml to an example file"

Or, if you’re on Subversion:

svn move config/database.yml config/database.yml.example
svn ci -m "moved database.yml to an example file"

Second, ignore the .yml version.

If you’re on Git:

cat > .gitignore
config/database.yml

git add .gitignore
git commit -m "ignored database.yml"

If you’re on Subversion:

svn propset svn:ignore config "database.yml"

Third, install Where’s your database.yml, dude?:

script/plugin install git://github.com/technicalpickles/wheres-your-database-yml-dude

That plugin alerts developers before any Rake tasks are run if they haven’t created their own local version of config/database.yml.

Fourth, set up a Capistrano deploy task:

# in RAILS_ROOT/config/deploy.rb:
after 'deploy:update_code', 'deploy:symlink_db'

namespace :deploy do
  desc "Symlinks the database.yml"
  task :symlink_db, :roles => :app do
    run "ln -nfs #{deploy_to}/shared/config/database.yml #{release_path}/config/database.yml"
  end
end

Fifth, upload the server’s version of database.yml:

scp config/database.yml my_server.com:/path_to_rails_app/shared/config/database.yml

I found this while researching random stuff about config files.  Let’s ignore how long it is and focus on the long term maintenance hassles.

First off, you have to make every change in at least two files.

Secondly, if you have more than 2 environments this system falls down.

Thirdly, if you have multiple developers with their own database.yml files this option sucks because they won’t get changes on git pull or svn up.

Fourthy,   if you want to run QA in production mode or development mode, it’s not gonna work.

A better solution

I’ll look into creating a gem that does this at some point, but this is how I envision it.

Files

database.yml.master

database.yml.qa

database.yml.production

database.yml.slave

When Rails goes to read out of database.yml, it will first read database.yml.master, then overrwrite any settings in there with database.yml.slave.   Capistrano will sym-link database.yml.save on deploy to the appropriate environment.  This way, when you make a change, it should be tracked in svn but your .slave file can have it’s own specific overrides.

Related posts:

1. GNU Emacs vs Aquamacs vs Cocoa/Carbon Emacs
2. Release with bugs
3. Maven: disable all database operations on package
4. Always growl when you are done running specs