ただの雑記です。
Railsの環境（env)
通常用意されているenvは
- 開発環境向けの
development - テストコードを走らせるための
test - 本番環境用の
production
がデフォルトで用意されている。
主には
- 開発/テストの用途でしか使わないgemの使い分け
- 再起動の簡略化やCSSのコンパイルを裏側で自動的に実行する、いわゆるDeveloper Experienceを向上するための仕組みの切り分け
- database.ymlなどの他ミドルウェアの接続情報の設定
などの観点で別れていることが多い
envの追加
このenvは自由に追加できる。
たとえば、production環境をミラーコピーしたサーバーをテスト目的でのみ使いたいという場合を想定してみましょう。このようなサーバーは通常「ステージングサーバー(staging server)」と呼ばれます。"staging"環境をサーバーに追加したいのであれば、config/environments/staging.rbというファイルを作成するだけで済みます。その際にはなるべくconfig/environmentsにある既存のファイルを流用し、必要な部分のみを変更するようにしてください。- Rails アプリケーションを設定する - Rails ガイド
ステージング環境用の設定を継ぎ足すべきか
Railsガイドにあるように staging のような環境を足したくなるが、一般的に足したい場合というのは
- 本番とステージング処理に差異を出したい
- 本番環境と検証（ステージング）環境でデータベースの接続先などが異なる
などのようなケースが想像できる。
1の場合はそもそもの「ステージング環境」の捉え方にもよるが、本番環境の動作を確認するための環境、としてよういするものなのに挙動を変えるというのはオススメできない。もし、「外部のAPIと連携するために外部通信はモックにしたい」などの要望であれば環境変数として API_MOCKING_FLG などの変数を設定してあげたほうが、直感的にわかりやすくなるし管理もしやすい
if ENV[API_MOCKING_FLG] == 1 # APIのモック処理 else # 通常のAPI処理 end
2の場合も同様で、接続情報は環境変数に逃がすことで解決が可能である。以下はdatabase.ymlの例。
production: adapter: mysql2 encoding: utf8 pool: 5 socket: /tmp/mysql.sock database: <%= ENV['DATABASE_SCHEMA_NAME'] %> host: <%= ENV['DATABASE_HOST'] %> username: <%= ENV['DATABASE_USER_NAME'] %> password: <%= ENV['DATABASE_PASSWORD'] %>
このように基本は production と変わりそうな値を外部から注入可能にしておくだけで大部分が解決できる。また、分けることでさまざまな起動設定を二重に同じものを設定しかなければいけない辛さも回避することができる。
