5

Web アプリの多段階展開のベスト プラクティスと一般的な理論は何ですか?

私は、Git、Capistrano、および Passenger を使用して Rails アプリをデプロイすることに特に関心があり、そのプロセスの要点を説明している投稿を見つけました。

各段階 (テスト、ステージング、本番) に関して、どのような考慮事項を考慮する必要がありますか? ステージを異なる物理サーバーにデプロイする必要がありますか? 多段階展開に関するヒントやアドバイスはありますか? 気をつけるべき障害はありますか？

一番、

ジェイコブ

4

3 に答える 3

1

私はいつも、デプロイ ターゲットごとに cap タスクを作成し、それらをコマンド ラインで使用してきました。

# deploy.rb
task :stage do
  server 10.0.0.1 ...
end

> cap stage deploy

ステージングではクリーンアップを行い、本番環境では行わないデプロイなど、各ターゲット タスク内でカスタマイズ タスクを定義することもできます。

これらのデプロイ ターゲット タスクは非常に大きなものになることはめったにないので、マルチ ステージ用のキャップ エクステンションをインストールするようなことのポイントを実際に見たことはありませんが、他の状況は異なる可能性があると思います。

本番環境は他の環境から分離する必要があると思います。そうしないと、ステージングなどのプロセスの誤動作が本番パフォーマンスに影響を与える危険性があります。

データベースを爆破して最新の本番ダンプから再ロードするなど、ステージングの便宜のために cap タスクを定義することがあります。これらのタスクは、設定された変数などを介してデプロイ ターゲットをチェックし、深夜のタイプミスに対する保険として本番環境での実行を拒否する必要があります。

deploy.rb に多くのカスタム ビヘイビアを配置するのは魅力的ですが、環境や cap API の変更に伴い、これは後戻りする傾向があり、多くのメンテナンス作業が必要になることがわかりました。

私が大規模な環境で見たもう 1 つの方法は、capistrano コントロール ポイントとして機能するように特別に設定された安定版ブランチを追跡するチェックアウトを備えたシェル アカウントを持つことです。ローカルではなく、そこで ssh して cap コマンドを実行します。これにより、ローカル チェックアウトの deploy.rb に変更があり、本番環境へのデプロイで使用する準備ができていないという問題を回避できます。これは git と svn ではそれほど問題ではありませんが、cap コマンドを実行している時点でローカルの deploy.rb が何であるかを注意深く考える必要があります。

Heroku は最近、この作業を本当に簡単にしており、EY やその他の企業もそれほど遅れをとっていません。

于 2009-06-07T05:00:00.143 に答える
0

私たちは、1年以上にわたってcapistrano多段展開を非常にうまく使用してきました。システムは、Rails環境ファイルとほぼ同じ方法で、各ステージのデプロイメントファイルを適切に分離します。セットアップと管理は非常に簡単でした。

于 2009-07-22T02:29:25.977 に答える
0

ステージングと本番の 2 つの異なるサーバー環境を用意することをお勧めします。私は常にテスト環境を無視します。テスト環境は本番環境と同じように機能しますが、完了するとデータベースがロールバックされます。両方を同じサーバーで実行すると、運用環境のパフォーマンスと安定性に悪影響を及ぼす可能性があります。ステージング環境でテストするために gem をアップグレードすると、本番環境に悪影響を及ぼし、ダウンタイムが発生する可能性があります。

両方のサーバーに同じバージョンの gem が存在することに十分注意する必要があります。アプリのバージョンがステージングでは機能するが、この種の不一致が原因で本番環境では機能しない場合、問題が発生する可能性があります。

何か問題が発生した場合に備えて、最後の展開をロールバックする準備ができているコンソール ウィンドウを常に開いています。それ以上のプロセスはありません。

お金を節約して、できるだけ安いステージング サーバーを購入してください。それを使うのはあなただけですよね？それらが同じプロバイダーからのものであることを確認してください。

于 2009-06-01T21:16:16.683 に答える