私たちの会社には、ステージングサーバーと本番サーバーがあります。最新のリリース後、それらを 1:1 の状態にしようとしています。いくつかのホストとその多くのインスタンスで実行されている Web アプリケーションがあります。
問題は、新しい機能を簡単にテストし、新しいリリースで新しいバグの作成を回避するために、ステージング サーバーと運用サーバーで同じアーキテクチャ (構造) の Web アプリケーションを使用することを私が支持していることです。
しかし、誰もが私の意見に同意するわけではありません。彼らにとって、ステージング アプリケーション インスタンス間で異なる接続を確立することはそれほど大きな問題ではありません。実動サーバーよりもステージングでアプリケーションとアプリケーション間の接続を増やすことさえあるかもしれません。
そのようなアプローチの長所と短所についてお聞きしたいですか？私に同意するいくつかの良い点、またはおそらく私が正しくないいくつかの悪い点を意味します. 結果などのいくつかの例。
ステージング サーバーが実稼働サーバーと大幅に異なる場合、ステージング サーバーでの展開とテストが成功しても、最終的に実稼働サーバーに展開したときに世界が崩壊するかどうかについてはあまりわかりません。
この明らかな欠点を補うために、あなたの同僚が好んで混沌とした状況に真の利点があるとは思いません。彼らは、ステージング サーバーの構成を運用サーバーの構成と完全に同期させないようにすることで、何を得ることができると主張していますか?!
ステージングは展開のリハーサルのようなものです。夜に着るのと同じ衣装を着ていない場合、それがフィットするかどうか、またはぶら下がっている部分につまずくことがないかどうかをどうやって知ることができますか.
より正式には、デプロイで問題を引き起こしたり隠したりする可能性のある違いを最小限に抑えるために、ステージング環境を本番環境にできるだけ近づけるようにします。同じモデルのディスクや同じネットワーク相互接続を常に使用できるとは限らないため、「できるだけ近い」と言っていることに注意してください。ただし、利用可能なリソース内でできることを最小限に抑えようとします。
Martin Fowlerは最近ブログで、ある環境から別の環境にカットオーバーできる同一の環境を用意して、ステージング環境をテスト後に実稼働環境にすることについて説明しました。彼は言います：
展開の自動化に関する課題の 1 つは、ソフトウェアをテストの最終段階から実際の運用に移行するカットオーバー自体です。通常、ダウンタイムを最小限に抑えるために、これを迅速に行う必要があります。Blue-Green デプロイ アプローチでは、2 つの運用環境を可能な限り同一にすることでこれを実現します。いつでも、そのうちの 1 つ (例として青としましょう) がライブです。ソフトウェアの新しいリリースを準備するとき、グリーン環境でテストの最終段階を行います。ソフトウェアがグリーン環境で動作するようになったら、ルーターを切り替えて、すべての着信要求がグリーン環境に送られるようにします。ブルー環境は現在アイドル状態です。
このようなアプローチは、今日の混沌とした環境に代わる優れた方法になると思います。あなたのチームを説得して頑張ってください！
ptomli が提案したように、「できるだけ近い」アプローチも使用します...これは主にコスト要因によるものです。5 台のサーバーを含むファームの場合、ステージングを 1 台のスタンドアロン サーバーにすることはお勧めしません。これは、ネットワーク層が関与するシナリオでも役立ちます。何らかの理由 (セキュリティなど) でネットワーク接続に影響を与えるパッチがある場合、単一のボックス ステージング サーバーでは、パッチ適用の「実際の影響」が反映されない可能性があります。