7

背景：
ステップ1->特定の構成でテストモードで実行することにより、アプリケーションのユニットテストと機能テストを実行するボックスがあります。
ステップ2->ステップ1が成功したら、別のボックスで、異なる構成セットを使用してテストモードでアプリケーションを実行することにより、アプリケーションの統合テストを実行します。
ステップ3->ステップ2が成功したら、パフォーマンステストボックスで本番モードで実行することにより、アプリケーションのパフォーマンステストを実行します。
ステップ4->ステップ3が成功すると、ビルドは安定していると見なされ、UATボックスはそのコードベースで更新され、アプリケーションは顧客のレビューとフィードバックのために本番モードで実行されます。ステップ5->顧客からのGOを使用して、プロダクションボックスがコードベースで更新されます。

上記の手順から、手順1と2で、アプリケーションがテストモードで実行されている間、構成が異なることがわかります。ステップ3、4、5の場合も同様です。

そのような状況で、推奨される方法は何ですか？YAML構成ファイルを持っていましたが、個人的には、多数の構成ファイルを維持するのは意味がないと感じました。そこで、
「環境ごとの構成ファイル」
から
「レールごとの構成ファイルモード、変数をLinux環境に外部化する」に変更しました。

私は正しい方向に進んでいますか？私の行動は、物事を単純化しませんか？

これら2つのアプローチの長所と短所は何ですか？

4

3 に答える 3

12

私の経験では、環境変数はlast-resortの構成オプションです。それらは絶対にその場所を持っていますが、アプリケーションは通常、他のより信頼性が高く、明示的に意図的な構成オプションを最初にチェックする必要があります。YAMLファイルから構成をロードし、フォールバックとして環境変数のみを使用することを強くお勧めします。環境変数がシステム全体のすべてに適用されることを常に想定し、ある時点で誤って設定が解除されたり、間違った値に設定されたりすることを想定してください。つまり、一部の構成ディレクトリが設定されていて、そのディレクトリへのアクセス許可がないため、アプリはseppukuをコミット/しないでください（さらに悪いことに、アプリがとして実行されたためにドライブをワイプしますroot）。または、おそらく、あなたのようなものRAILS_ENVがに設定されましたtestあるべきだったのに誰も気付かproductionなかったのに、今ではユーザーが間違った場所に、または/dev/null500台すべてのためにデータを書き込んでいます。

logger.warn個人的には、構成値の環境変数にフォールバックするたびにメッセージをドロップするのが好きです。

あなたの正確な問題については、正直なところ、コマンドラインで開始する環境の構成値を渡すと思います。

于 2011-01-12T23:25:26.470 に答える
0

多くのグーグルが無駄になり、Railsの人々と話し合い、ブレインストーミングを行った後、コードを変更して、「Railsモードごとの構成ファイル、アプリケーション構成をYMLファイルに外部化する」ようにしました。 Rails環境の外」

自明のコードスニペットをたどって、私が簡単な方法でそれを達成する方法を理解してください。簡単に説明すると、environment.rbファイルのコードスニペットがシステムからYAMLファイルを読み取り、すべてのキーと値のペアをRailsのENVハッシュにコピーします。このENVハッシュは、アプリケーションのロード中/オン/後のどこでも利用できます。

File: config/environment.rb
# Mechanism to load all application related configurations
$CONFIG_FILE = "/var/myapp/config/jsconfig.yml"
require 'yaml'
APP_CONFIG = YAML.load_file($CONFIG_FILE)
APP_CONFIG.each do |key, value|
  ENV[key] = value
end

#3rd Party Server's (that my application is using) Configurations here...
3RD_PARTY_SERVER_URL = ENV['3rd_party_webservice_endpoint_url']
3RD_PARTY_SERVER_CREDENTIALS = {:username => ENV['3rd_party_server_username'], :password=> ENV['3rd_party_server_password']}


File: /var/myapp/config/jsconfig.yml
3rd_party_webservice_endpoint_url: url
3rd_party_server_username: username
3rd_party_server_password: password
myapp_db_url: jdbc:oracle:thin:@localhost:1521:XE
myapp_db_username: kartz
myapp_db_password: rails_savvy


File: /var/myapp/config/database.yml
development:
  adapter: oracle_enhanced
  url: <%= ENV['myapp_db_url'] %>
  username: <%= ENV['myapp_db_username'] %>
  password: <%= ENV['myapp_db_password'] %>
  encoding: utf8

test:
  adapter: oracle_enhanced
  url: <%= ENV['myapp_db_url'] %>
  username: <%= ENV['myapp_db_username'] %>
  password: <%= ENV['myapp_db_password'] %>
  encoding: utf8

production:
  adapter: oracle_enhanced
  url: <%= ENV['myapp_db_url'] %>
  username: <%= ENV['myapp_db_username'] %>
  password: <%= ENV['myapp_db_password'] %>
  encoding: utf8

詳細については、私のブログ投稿をご覧ください：https ://blog.codonomics.com/2011/02/externalizing-all-application-specific.html

于 2011-02-02T17:28:54.823 に答える
0

私の会社には、ある意味で両方があります。

別のソフトウェアのさまざまなインストールの1つをポイントし、そのインストールのAPIを使用できるRailsアプリがあります。インストールを指定するには、約5つの変数を設定する必要があります。

これらの変数はそれぞれ個別の環境変数として使用していましたが、すべてを設定すると非常に早く古くなり、必然的に1つを忘れてしまいました。

これで、ENV_TOKENと呼んでいる環境変数が1つあり、有効なENV_TOKEN変数に対応するエントリを含むyamlファイルと、ENV [key]=valueを設定するconfig/initializersのコードがあります。

したがって、それぞれ「1」と「2」に設定したい変数「FOO」と「BAR」があるとします。以下を含むyamlファイルを作成できます。

carolclarinet:
  FOO: one
  BAR: two

次に、環境変数ENV_TOKENをcarolclarinetに設定し、FOOとBARを1と2に設定します。

これが最善の方法かどうかはわかりませんが、うまくいきます。

ETA：これは開発とテスト専用であることに注意してください。お客様が環境変数を変更しないように、ソフトウェアのインストーラーがこれらすべての設定を処理します。

于 2011-01-12T22:11:28.303 に答える