質問: database.ymlの扱い方についてベストプラクティスがあればご教示いただきたく質問しました。 私はいつも以下の方法でdatabase.ymlを運用しています。 1. `config/database.yml` を `config/database.yml.default` などにリネーム 2. `.gitignore` に `config/database.yml` `config/database.yml.default` を追加してバージョン管理から外す 3. git clone 後にdevelopmentでは `cp config/database.yml.default config/database.yml` をする productionでは `/var/www/app_name/shared/config/database.yml` を作成しています。 このように運用するメリットは、 1. (database.ymlにDBのパスワードを記載していた場合) パスワードが記載されたファイルをバージョン管理しなくて良い 2. developmentのDBの設定は開発者に依存するため、 パスワードを空にしている人やパスワードを設定している人がいた場合、database.ymlをバージョン管理しない方が使い勝手が良い などがあります。 ただ、最近マストドンのdatabase.ymlを見ていたところ、パスワードなどは環境変数から取得するようになっていることと、rails new した際のデフォルトはdatabase.ymlとなっていてrailsとしてはdatabase.ymlはバージョン管理される前提になっているのではと思うようになりました。 そこで他の方のdatabase.ymlの管理方法やベストプラクティスがあれば伺いたくこのような質問をしました。
回答: 質問者さんの管理方法で問題あるかと言われたら、ないと思います。 強いて言えば、database.yml には開発、テスト、プロダクションの3種類が定義でき、そのプロファクションの部分だけを環境変数から取得するように記述しておき、それをそのままバージョン管理するというやり方が、結構普通に使われていると思います。というのも、Railsで自動生成されたdatabase.ymlを見ると最初から環境ごとに別れた設定になっているからです。 これにはdotenvというgemを使って応用する人もいれば、環境変数をきちんと設定する形で運用する人もいます。 ただどっちにしても、本番運用するデータベースのパスワードなどをバージョン管理するのはあまり無邪気に勧められることではなくて(根拠があってやるなら別ですが)、バージョン管理するにしても別リポジトリなどで設定内容を持っておくとか、デプロイ時に使うツール(capistrano等)のソースとして管理といったことをしている場合が、私が見てきた範囲で多かったように思います。それで特に問題は起きてません。 ベストプラクティスか統計をとったわけではないのでわかりませんが、ご参考までに。