ステージングのポイントは何ですか?


18

私はこれを解決したと思っていましたが、Continuous Delivery(優れた本)を読んだ後、少し混乱しています。彼らは以下のためのサーバーを持つことについて話します:

  • 開発
  • さまざまな形式の自動テスト
  • ユーザー受け入れテスト(UAT)-つまり、クライアントと一緒に座って彼らにそれをデモンストレーションし、彼らに探索的テストをさせます。社内のテスターは、この設定を探索的テストにも使用できます。
  • 演出
  • 製造。

ステージングは​​常にUAT機能を提供すると考えていましたが、ステージングは​​別のレベルとしてステージングされているようです。そのスキームでは、ステージングサーバーはどのような機能を提供しますか?


10
その方法論に同意するとは言えません。UATは、常にライブシステムに可能な限り近い仕様(つまり、ステージング)で実行する必要があります。私たちがUATを実行し、誰もが速度の問題について不平を言う回数を数えることはできません。それに対して、「ライブシステムはより高速になる」と1000回説明する必要があります。そして、コードのバグやSQLクエリが原因でライブシステムが高速にならない場合は、自分の言葉を食べる必要があります。
マークヘンダーソン

UAT =ユーザー受け入れテストですよね?
マーティントーマ

回答:


13

ステージングでは、製品システム全体を配置しますが、実際にはまだ使用していません。それらが使用されると、「生産」になります。使用するすべてを所定の位置に配置し、テストしてからスイッチを切り替えます。

UATは通常、実稼働で使用されるハードウェア/ソフトウェア/構成とは大幅に異なる「テスト」環境を使用します。

たとえば、私が働いている場所では、サーバー上で実行されているVM環境ですべてをテストする顧客がいます。システムが稼働すると、施設でハードウェア上で実行され、おそらく既存のシステムと統合されます。サーバーやテスト環境とはまったく関係ありません(コードと一部の構成がそこからコピーされていることを除いて...)


UATだけでなく、実稼働に入る直前に、通常、ステージングサーバーでもより多くのテストが行​​われます。
-jftuga

3
@jftuga、...最初の段落の最後の文を参照してください
クリスS

@Chris S:私があなたを正しく理解していれば、「ステージングサーバー」というようなものは存在しません。プールから出て、現在エンドユーザーにサービスを提供していない本番サーバーだけです。それは理にかなっており、私が従う方法論ですが、これらのサーバーを「ステージングサーバー」とは呼ばず、本番サーバー(プールにない)だけと呼びます。ステージングサーバーを使用する私が作業したすべての場所で、それらが個別のサーバーとして使用されているため、ステージングサーバーの説明がその用語の標準的な使用であるとは思いません。良いアイデアですが、「ステージングサーバー」が通常意味するものではありません(とにかく私の経験では)。
iconoclast

1
@Brandonでは、「ステージングサーバー」とは何ですか?これは、サーバーの「バウンス」のような地域的な違いかもしれません。
クリスS

組織によって異なるように思えます。開発者が本番環境とおそらく同じ環境にアプリを配置するためのサーバーとして、UATサーバーとして使用されるのを見てきました。(個人的には、実際のプロダクションサーバーを使用してステージングすることが唯一の良い戦略だと思います。)さまざまな組織が独自の文化を開発するにつれて、彼らは独自のレキシコンも開発すると思います。残念ながらしないでください。
iconoclast

17

私は非常に大きなインターネット会社のリリース管理チームで働いています。上記のプロセスを基本的に使用し、意図的にそのプロセスを選択しました。私たちの方法論では、ステージングは​​本番環境でのテストの最終レベルの分岐メカニズムとして機能します。

本番環境に移行する前にすべてのテストを実行したいのは明らかですが、多くのユーザーがいる大規模で複雑な環境では、到達するのが非常に難しい目標です。特に、QAにテストソフトウェアを適切にロードすることは事実上不可能です。機能テストは、負荷テストよりも自動化がはるかに簡単です。何千ものユーザーがサーバーにアクセスすると、物事は奇妙で予測しにくい方法で失敗します。

だからここに私たちがやっていることです:

  • 開発
    • 継続的な統合と自動化されたテストが含まれます
  • リリーステスト
    • 私のグループはリリース自体を分析します
    • インストールログの確認
    • ロールバックのテスト
  • QA
    • ユーザー受け入れテスト

それが、ステージングとプロダクションの間で分岐するポイントです。リリースには列車モデルを使用し、数週間ごとに新しい列車を開始します。番号が付けられた列車でも、ステージングサーバー(運用中)に行きます。奇数番号の列車はそうではありません。

偶数トレインの間に、開発者は個々の変更をステージングサーバーにプッシュすることができます(もちろんそれらの変更がQAによってテストされた)。これにより、実際の本番環境でソフトウェアが期待どおりに動作することを検証できます。これは通常、リスクが高いと見なされるコンポーネント専用です。すべての小さなピースをステージングにプッシュするわけではありません。

それから、誰もが次の偶数列車が始まると、ステージングサーバーの内容を消去し、列車のベースラインに戻すことを理解しています。開発者は、変更が確実にトレインに反映されるようにするか、まだ一般的な使用の準備ができていないことを確認します。その場合、これらの変更はステージングサーバーで消去されます。

要約すると、(少なくとも私たちにとって)簡単な答えは、QAで複雑なシステムを完全にテストすることは不可能だということです。ステージングは​​、限られた本番テストを行う安全な方法を提供します。

関連するメモとして、リリースプロセスのしくみについて説明したプレゼンテーションのスライドを以下に示します。


5

ステージングの最も簡単な説明は、展開プロセスのテストと実際のデータソースを使用したテストです。一部のシステムはステージングとテスト環境を組み合わせていますが、大規模システムの場合、展開プロセスは非常に複雑になるか、ライブ/プロダクションデータソースに接続した後に追加のテスト手順が必要になる場合があります。これらの場合、ステージング環境を使用すると、展開プロセスをテストし、ライブデータを使用して最後のバグを確認できます。動作が確認されたら、ステージ環境を運用環境にすばやく切り替えることができます。

たとえば、Windows Azureは、新しいバージョンの展開に5〜25分かかりますが、ステージング環境に展開し、テストを実行して、すぐに運用環境とステージング環境を交換できます


弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.