Quelle est la meilleure façon de gérer le fichier database.yml de Rails si plusieurs personnes travaillent sur le projet et que les emplacements de la base de données sont différents (le socket en particulier).
Réponses
Trop de publicités?Tout d'abord, déplacez database.yml
d'un fichier de modèle.
Si vous êtes sur Git:
git mv config/database.yml config/database.yml.example
git commit -m "moved database.yml to an example file"
Ou, si vous êtes sur la Subversion:
svn move config/database.yml config/database.yml.example
svn ci -m "moved database.yml to an example file"
Deuxième, ignorez-le .yml version.
Si vous êtes sur Git:
cat > .gitignore
config/database.yml
git add .gitignore
git commit -m "ignored database.yml"
Si vous êtes sur la Subversion:
svn propset svn:ignore config "database.yml"
Troisièmement, installer Où est votre base de données.yml, mec?:
script/plugin install git://github.com/technicalpickles/wheres-your-database-yml-dude
Ce plugin alertes développeurs avant tout prélèvement tâches sont exécutées si elles n'ont pas créé leur propre version locale de l' config/database.yml
.
Quatrièmement, mettre en place un Capistrano tâche de déploiement:
# 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
Cinquième, télécharger la version du serveur de base de données.yml:
scp config/database.yml user@my_server.com:/path_to_rails_app/shared/config/database.yml
Encore une autre méthode qui utilise capistrano un ERb pour demander les informations d’identification lors du déploiement.
http://www.simonecarletti.com/blog/2009/06/Capistrano-and-Database-yml/
En plus des réponses ci-dessus, j'ai écrit une tâche rake similaires à "Où est votre base de données.yml, mec?", mais en permettant de garder le modèle des exemples de fichier de configuration. Check it out: https://github.com/Velid/exemplify
Comme une alternative à l'écriture de la production séparée de configurations et de les relier via Capistrano, je vous suggère aussi d'utiliser des variables d'environnement pour vos identifiants:
password: <%= ENV['PROD_DATABASE_PASSWORD'] %>
Il y a beaucoup de pratique des outils et des moyens pour ce faire disponible partout.