エンドツーエンドパイプラインモニタリング
エンドツーエンド(E2E)テストパイプライン
テストパイプラインはスケジュールに基づいて実行され、その結果はSlackに投稿されます。以下は毎日モニタリングされているエンドツーエンドテストパイプラインです。
NOTE: エンドツーエンドテストとパイプラインの失敗を調査する方法については、失敗するテストとテストパイプラインのデバッグをご確認ください。
ビジュアルパイプライン環境マップ

この図は、エンドツーエンドテストパイプラインがインフラストラクチャの様々な環境にどのようにマッピングされるかを視覚的に示しています。マージリクエスト、開発、ステージング、プレプロ、本番環境でのテストのフローを示し、テストがいつトリガーされるか(コミット時、デプロイ後、設定変更後など)と各環境でどの種類のテストが実行されるか(スモーク、フルなど)を示しています。
カラーコーディングはテストの種類と環境カテゴリを示しており、デプロイパイプライン全体にわたる包括的なテスト戦略を理解しやすくしています。この視覚化はインフラストラクチャ計画に特に価値があります。元のLucidChartダイアグラムにはCellsバージョンも含まれており、どのように見えるかを視覚化できます。
テストメトリクス
テストの健全性を可視化するために、テスト実行結果を以下にエクスポートしています。
- InfluxDbインスタンスとGrafanaダッシュボードを使用して結果を視覚化
- Google Cloud Storage (GCS)インスタンス。Snowflakeからアクセス可能
テストレポート
Allureレポート
テスト結果を提示するもう一つのツールとして、Allureテストレポートがあります。パイプラインで実行されたテストはAllureレポートを生成します。QAフレームワークはAllure RSpec gemを使用してAllureテストレポートのソースファイルを生成します。パイプラインの追加ジョブが以下を行います。
- すべてのテストジョブからこれらのソースファイルを取得します。
- レポートを生成し、
AWSグループプロジェクトeng-quality-ops-ci-cd-shared-infraにあるS3バケットgitlab-qa-allure-reportにアップロードします。
各種類のスケジュールされたパイプラインは、その段階に応じた最新のテストレポートへの静的リンクを生成します。
| 環境 | 説明 | リンク |
|---|---|---|
master (gdk) | Dockerコンテナにパッケージされたgitlab-development-kit環境に対するE2Eテスト実行。 | e2e-test-on-gdk |
master (test-on-omnibus) | omnibusイメージの様々な設定に対するE2Eテスト実行。 | e2e-test-on-omnibus |
nightly | omnibusナイトリーイメージの様々な設定に対するE2Eテスト実行。 | nightly |
staging-full | https://staging.gitlab.com環境に対するE2Eテスト実行。 | staging-full |
staging-sanity | omnibusナイトリーイメージの様々な設定に対するE2Eテスト実行。 | staging-sanity |
staging-ref-full | https://staging-ref.gitlab.com環境に対するE2Eテスト実行。 | staging-ref-full |
staging-ref-sanity | https://staging-ref.gitlab.com環境に対するE2Eテスト実行。 | staging-ref-sanity |
preprod | https://pre.gitlab.com環境に対するE2Eテスト実行。 | preprod-sanity |
production-full | https://gitlab.com環境に対するE2Eテスト実行。 | production-full |
production-sanity | https://gitlab.com環境に対するE2Eテスト実行。 | production-sanity |
これらのレポートはSlackのパイプラインステータスアラートにも含まれます。
テストセッションIssue
テストが実行される様々な環境について、自動テストを行う各エンドツーエンドパイプラインに対して、テストセッション情報を含むテストセッションIssueを作成します。テストセッションIssueはDevOpsステージでテスト結果をグループ化し、テストケースおよびテスト失敗Issueにリンクします。
テストセッションIssueの例: https://gitlab.com/gitlab-org/quality/testcase-sessions/-/issues/72516
テストセッションIssueはGitLab機能の欠落に対する回避策です。GitLabがテストデータを保存するようになれば、失敗のレポートと管理を改善できます。
テスト結果Issue
各テストはGitLab テストケースに関連付けられています。
RSpec.describe 'Stage' do
describe 'General description of the feature under test' do
it 'test name', testcase: 'https://gitlab.com/gitlab-org/gitlab/-/quality/test_cases/:test_case_id' do
...
end
it 'another test', testcase: 'https://gitlab.com/gitlab-org/gitlab/-/quality/test_cases/:another_test_case_id' do
...
end
end
end
テスト失敗スタックトレースとIssueスタックトレースが比較され、スタックトレースが(15%の差異しきい値以内で)テスト失敗に最も似ている既存のIssueが使用されます。テスト失敗ジョブは、IssueのFailureレポートリストに追加されます。グループラベルはテストのproduct_groupメタデータに基づいて自動的に推定されます。
