私はこれを解決したと思いましたが、 Continuous Delivery (優れた本)を読んだ後、私は少し混乱しています。彼らは以下のためのサーバーを持っていることについて話します:
私は常にステージングをUAT機能を提供するものとして考えていましたが、それらは別個のレベルとしてステージングを持っているようです。では、そのスキームでは、ステージングサーバーはどのような機能を提供するのでしょうか。
ステージングでは、完全な製品システムを配備しますが、実際にはまだ使用していません。それらが使用されるときは「生産」になります。使用するすべてのものを所定の位置に配置し、テストしてから、スイッチを切り替える必要があります。
UATは通常、本番環境で使用されるハードウェア/ソフトウェア/構成とは大幅に異なる「テスト」環境を使用します。
たとえば、私が作業している場所では、VM環境でサーバー上ですべてをテストしています。システムが稼働すると、ハードウェア上で、おそらく施設と統合して実行されます。彼らの既存のシステム;それは私たちのサーバーやテスト環境とはまったく関係ありません(コードといくつかの設定がそこからコピーされていることを除いて...)
私は非常に大規模なインターネット会社のリリース管理チームで働いています。私たちは基本的に上記で概説したプロセスを使用し、そのプロセスを意図的に選択しました。私たちの方法論では、ステージングは、本番環境での最終レベルのテストの分岐メカニズムとして機能します。
明らかに、本番環境に移行する前にすべてのテストを実行する必要がありますが、多数のユーザーがいる大規模で複雑な環境では、これを達成するのは非常に困難です。特に、QAでテストソフトウェアを適切にロードすることは事実上不可能です。機能テストは、負荷テストよりもはるかに簡単に自動化できます。何千人ものユーザーがサーバーにアクセスする場合、奇妙で失敗を予測するのは困難です。
だからここに私たちがすることです:
これが、ステージングと本番の間で分岐するポイントです。リリースにはトレインモデルを使用し、数週間ごとに新しいトレインを開始します。番号が付けられたトレインでもステージングサーバー(稼働中)に行きます。奇数番号の列車にはありません。
偶数列の間に、開発者はステージングサーバーに個々の変更をプッシュする機能があります(もちろん、これらの変更はQAによってテストされています(後)。これにより、実際の運用環境でソフトウェアが期待どおりに動作することを検証できます。これは一般に、リスクが高いと思われるコンポーネントのために予約されており、すべての小さな要素をステージングにプッシュするわけではありません。
次に、次の偶数トレインが開始されると、ステージングサーバーの内容が消去され、トレインベースラインに戻されることを誰もが理解しています。開発者は、変更が確実に反映されるようにするか、まだ一般的な使用の準備が整っていないと判断します。この場合、これらの変更はステージングサーバーで消去されるだけです。
要約すると、(少なくとも私たちにとって)短い答えは、QAで複雑なシステムを完全にテストすることは不可能であるということです。ステージングは、限られた生産テストを行う安全な方法を提供します。
関連するメモとして、これが私の プレゼンテーションからのスライド です。リリースプロセスのしくみについて説明しました。
ステージングの最も簡単な説明は、展開プロセスのテストと実際のデータソースを使用したテストです。一部のシステムはステージングとテスト環境を組み合わせていますが、大規模なシステムの場合、展開プロセスが非常に複雑になったり、ライブ/本番データソースに接続した後に追加のテスト手順が必要になる場合があります。このような場合、ステージング環境では、展開プロセスをテストし、ライブデータを使用して直前のバグを確認できます。その後、動作が確認されたら、ステージング環境を本番環境にすばやく切り替えることができます。
この例としては、Windows Azureがあり、新しいバージョンをデプロイするのに5〜25分かかりますが、ステージング環境にデプロイしてテストを実行した後、 本番環境とステージング環境を即座にスワップする を使用できます。