私は非常に大きなインターネット会社のリリース管理チームで働いています。上記のプロセスを基本的に使用し、意図的にそのプロセスを選択しました。私たちの方法論では、ステージングは本番環境でのテストの最終レベルの分岐メカニズムとして機能します。
本番環境に移行する前にすべてのテストを実行したいのは明らかですが、多くのユーザーがいる大規模で複雑な環境では、到達するのが非常に難しい目標です。特に、QAにテストソフトウェアを適切にロードすることは事実上不可能です。機能テストは、負荷テストよりも自動化がはるかに簡単です。何千ものユーザーがサーバーにアクセスすると、物事は奇妙で予測しにくい方法で失敗します。
だからここに私たちがやっていることです:
- 開発
- リリーステスト
- 私のグループはリリース自体を分析します
- インストールログの確認
- ロールバックのテスト
- QA
それが、ステージングとプロダクションの間で分岐するポイントです。リリースには列車モデルを使用し、数週間ごとに新しい列車を開始します。番号が付けられた列車でも、ステージングサーバー(運用中)に行きます。奇数番号の列車はそうではありません。
偶数トレインの間に、開発者は個々の変更をステージングサーバーにプッシュすることができます(もちろん、それらの変更がQAによってテストされた後)。これにより、実際の本番環境でソフトウェアが期待どおりに動作することを検証できます。これは通常、リスクが高いと見なされるコンポーネント専用です。すべての小さなピースをステージングにプッシュするわけではありません。
それから、誰もが次の偶数列車が始まると、ステージングサーバーの内容を消去し、列車のベースラインに戻すことを理解しています。開発者は、変更が確実にトレインに反映されるようにするか、まだ一般的な使用の準備ができていないことを確認します。その場合、これらの変更はステージングサーバーで消去されます。
要約すると、(少なくとも私たちにとって)簡単な答えは、QAで複雑なシステムを完全にテストすることは不可能だということです。ステージングは、限られた本番テストを行う安全な方法を提供します。
関連するメモとして、リリースプロセスのしくみについて説明したプレゼンテーションのスライドを以下に示します。