アプリをカバーする単体テスト、統合テスト、e2e テストがたくさんあるとします。これらを prod に対して継続的に (たとえば 10 分ごとに) 実行することは理にかなっていますか?
いいえと考えています。理由は次のとおりです。私のテストは、すべての製品がデプロイされた後に既に実行されています。それらが合格し、その後コードが変更されていない場合は、引き続き合格する必要があります。したがって、その後それらをテストしても意味がありません。
本当に継続的にテストしたいのは、インフラストラクチャです。まだ稼働していますか? この場合、API 統合テストを 10 分ごとに実行して、API がまだ機能しているかどうかを確認することは理にかなっています。そのため、私はテスト スイートのサブセットを扱っています。これは、インフラストラクチャの可用性 (統合 + e2e) と単一ビットのコード (単体テスト) をテストするものです。実際には、デプロイ前/デプロイ後のテストに使用されるスイートとは異なり、製品稼働時間をテストする別のテスト スイートを用意することになりますか?
このような「冗長な」検証 (テストだけでなく、ビルドも含めることができます) は、実際の生産プロセスの監視精度を高める追加のデータポイントを提供します。
本番環境の複雑さによっては、単純な「稼働中ですか?」質問には簡単な答えがない可能性があり、検証のサブセット/ショートカットバージョンはそれをカットしない可能性があります-実際の本番バージョンではなく、それらのバージョンのみをカバーします.
たとえば、ビルド サーバーが稼働しているからといって、製品を正常にビルドできるとは限らないため、ビルド自体のあらゆる側面(すべてのツール、ストレージ、依存関係、OS リソースなど) の可用性を確認する必要があります。複雑なビルドでは、ビルドが実行可能かどうかを確実にチェックするコードを管理するよりも、ビルド自体を実行する方がおそらく簡単です;)
より正確な監視の恩恵を受ける生産プロセス属性が 2 つあります (サブセット/ショートカット検証も適していません)。
これらのいずれかが適用可能であるか、コンテキストに許容できるコスト/利益比があるかどうかはわかりませんが、非常に大規模で複雑なほとんどの SW プロジェクトにとって重要であることは間違いありません。