前置き
CI/CDパイプライン中に組み込まれたテストでも、
・毎回実行するもの
・特定のイベントトリガーが走った時のみ実行
とで分かれると思います。
この後者の何かしらのイベントが走った時というのは、イベント駆動アーキテクチャの考えが適用できます。
このアプローチは、
「すべてのテストを毎回実行する」という非効率なモノリシック・パイプライン
から、
「必要なテストを、必要な時にだけ実行する」 という疎結合 & 効率的
なパイプラインアーキテクチャへと進化させる鍵となります。
この設計では、CI/CDツール（Jenkins, GitLab CI, GitHub Actionsなど）が 「イベントブローカー」 のように振る舞います。
1. イベントの発行 (Publish)
開発者のアクションやシステムの状態が 「イベント」 として発行されます。
・code_committed_to_feature_branch (フィーチャーブランチへのコミット)
・pull_request_opened (プルリクエストの作成)
・pull_request_merged_to_main (mainブランチへのマージ)
・tag_pushed (v1.2.0) (リリースタグの発行)
・nightly_schedule (夜間スケジュールの発動)
・external_api_contract_changed (外部APIの契約変更通知)
2. イベントの購読 (Subscribe) と実行
パイプライン内の各テストプロセス（ジョブ）は、「消費者（Consumer）」として、
自分が関心のあるイベントだけを 「購読（Subscribe）」 します。
①. 毎回実行するテスト (例：ユニットテスト、Lint)
・購読するイベント：code_committed_to_feature_branch
・目的：開発者への最速のフィードバック。
②. 特定のイベントで実行するテスト
例：統合テスト、コントラクトテスト
・購読するイベント：pull_request_opened
・目的：マージ前に、ブランチ間の結合性を検証する。
例：E2Eテスト、負荷テスト、カオス実験
・購読するイベント：nightly_schedule (夜間)
・目的：リソースを大量に消費する重いテストは、開発者の邪魔にならない夜間に実行。
例：本番デプロイプロセス
・購読するイベント：tag_pushed
・目的：リリースタSタグが打たれた時だけ、本番環境へのデプロイを実行する。
このアーキテクチャのメリット (ECRS)
このイベント駆動型アプローチは、ECRS原則を適用した結果とも言えます。
E (Eliminate - 排除)
開発者の 「待ち時間」を排除 します。
コミットのたびにE2Eテスト（例：40分）の完了を待つ必要がなくなり、ユニットテスト（例：2分）の結果だけを高速に受け取れます。
R (Reorder - 順序変更)
重いテスト（E2E）を、開発者のクリティカルパス（コミット→フィードバック）の
「外」（例：夜間）に順序変更（移動）しています。
これにより、開発者の生産性（リードタイム）と、システム全体の品質保証を両立させることが可能になります。