本番環境のテスト戦略
理想的な世界では、開発者と運用担当者が1つのチームとして共同で何かを製品にリリースしています。
ただし、リリースエンジニア/チームが開発/プロジェクトチームから完全に離れるように制限されている組織もあります。
これにより、リリースに関するコミュニケーションの問題が追加されただけでなく、プロダクション環境がプロジェクトチームからほとんど見えなくなりました。ある程度、プロジェクトと展開チームの間には「信頼の危機」があります。
UAT環境には良好で信頼性の高い受け入れ/機能テストがありますが、展開プロセスが適切に行われているか、すべてがUATとまったく同じように運用環境で機能しているかどうかはわかりません。したがって、これを確認できる唯一の方法は、実稼働環境でのいくつかのテストによるものです。
いくつかの簡単な煙のテストは、接続の問題を特定するのに役立ちます。
だから私の質問は：UATで行ったすべてのテストを運用環境に適用することについてのあなたの意見は何ですか（データの削除など、運用環境で発生させたくないビットを無効にする構成を使用）
同様のことを行った場合、監査証跡を汚さずに本番環境でデータを再生するにはどうすればよいですか（アカウントに基づくことは明らかですが、アカウントによる分離はないと仮定しましょう）。
編集：私は常に製品環境をテストすることを意味していませんでしたが、展開直後にのみです。また、ルートとdev/opの関係から問題を解決しようとするのをやめません。しかし、同時に他の可能性を模索したいと思います。
通常、テストは次の3つの理由で本番サーバーの外部で実行されます。
安全性。何かがうまくいかず、ステージングからのすべてのデータが誤って削除されても、気にする必要はありません。本番環境で発生する場合、それは... 迷惑としましょう。
パフォーマンス。広範なテストスイートでは、数分間、複数のサーバーで100％のCPUを簡単に使用できます。 1時間に10回、数分間、運用サーバーの速度を落とすことはできません。
ゴール。テストの目的は、本番環境での問題を防ぐことです。アプリケーションが既にデプロイされているときに問題を見つけた場合は、手遅れです。さらに、以前のリビジョンに戻すのは複雑になる可能性があります。たとえば、新しいバージョンがデータベースに列を作成し、その間にこの新しい列が使用された新しいレコードがある場合はどうなりますか？
これらの理由から、本番環境をテストに使用しないことを強くお勧めします。さらに、本番環境でテストを実行して結果をチームに送り返すことは、システム管理者の信頼を得るのに役立つとは思いません。彼らはtheirインフラストラクチャをyour teamから保護するために設定した制限を回避するための暫定的なものとして認識するかもしれません。
代わりに、元の問題、つまり開発者とシステム管理者の間の信頼の欠如に対処してください。コミュニケーションと信頼の問題がこのレベルに存在するまで、テストと展開のプロセスwillは、それを容易にするために使用するトリックに関係なく、苦痛です。
堅牢なバージョン管理システムを実装した場合、基本的な機能を確認するだけでよいようにテストを分散します。
例として、以下は4つの環境で実行されます（簡潔にするために簡略化しています）。
- DEV：単体テスト、いくつかの行動テスト
- FAT：統合テスト、回帰テスト、インストールテスト
- UAT：LIVEへの展開のテスト（おそらく偽のデータを使用）
- LIVE：共通機能、可能な環境テスト
DEV（開発）環境
新機能、バグ修正、および以前のテストをテストするための単体テストに焦点が当てられています。新しい/変更された機能に必要な場合、いくつかの動作テストを実行できます。
FAT（工場受け入れテスト）環境
インストーラーをテストし、テスターがアプリケーションを実行して、新しい機能とバグ修正をテストできるようにし、古い機能が回帰テストで壊れていないことを確認します。
AT（ユーザー受け入れテスト）環境
クライアント/顧客/ユーザーは、アプリケーションをテストして、期待どおりに機能することを確認します。注目すべきは、UATはLIVEと同じであるべきであり、ここで機能するものはLIVEでも機能することです。
LIVE（本番）環境
最新バージョンへのアップデートを完了し、基本（煙テスト）を再確認するだけです。データにアクセスしたり、レポートを開いたり、ドキュメントを表示したり、データをエクスポート/インポートしたりできます。
ソフトウェアがLIVE環境に到達するまでに、以前のすべての環境に問題なく合格しているため、再テストする必要はありません。何らかの理由で何らかの環境で障害が発生した場合、ソフトウェアリリースはDEVに戻り、変更が加えられ、新しいリリース番号の下でプロセス全体が再び開始されます。 1.2.3.0-> 1.2.3.1。
LIVEで再テストする必要がないように、各環境を通過してテストを完了することにより、LIVEへのリリースへの信頼を築きます。