テスト検疫プロセス
このページでは、フレーキーおよび壊れたテストを管理するための GitLab の検疫プロセスについて説明します。技術的な実装の構文（RSpec と Jest）については、テストの検疫（開発者ドキュメント）を参照してください。フレーキーテストのデバッグについては、不健全なテスト（開発者ドキュメント）を参照してください。
検疫プロセスは、将来修正するために保持しながら、フレーキーまたは壊れたテストを CI 実行から一時的に削除することでパイプラインの安定性を維持するのに役立ちます。テスト失敗のノイズを減らし、エンジニアが無関係な失敗によってブロックされないようにします。テストの検疫は一時的なものであるべきです：テストは修正、削除、またはより低いテストレベルに移動されなければなりません。
クイックナビゲーション
| シナリオ | 対処方法 |
|---|---|
| 検疫 MR が割り当てられた | レビューしてアクションを取る |
| テストを検疫する必要がある | 検疫ライフサイクル |
| テストの検疫を解除したい | 検疫解除プロセスに従う |
| テストはどのようにして検疫されるか？ | 自動検出と手動プロセス |
| データはどこにあるか？ | フレーキーテストの検出と追跡 |
| ヘルプが必要 | Slack チャンネルとサポート |
検疫マージリクエストが割り当てられた場合
検疫マージリクエストが割り当てられた場合、テストの検疫をレビューする適切な DRI として特定されています。これらのマージリクエストは継続的に失敗するフレーキーテストに対して自動的に作成されますが、チームメンバーが手動で作成することもできます。
対処方法：
- 最善のアプローチをレビューして決定する：
- すぐに修正する：根本原因が明確で修正方法がわかっている場合。
- テストを削除する：価値が低いか冗長な場合。
- より低いレベルに変換する：ユニットまたは統合レベルでより確実にテストできる場合。
- 検疫する：調査または修正が必要な応答時間よりも長くかかる場合（特定のタイムラインについてはフレーキーテスト - 緊急度ティアと応答タイムラインを参照）。
- 応答タイムラインに従ってアクションを取る（特定のタイムラインについてはフレーキーテスト - 緊急度ティアと応答タイムラインを参照）：
- マージリクエストをマージする（テストが検疫に入る）、または
- テストを修正してマージリクエストをクローズする、または
- 検疫すべきではない理由についてフィードバックを提供する。
アクションが取られなかった場合：
- マージリクエストは緊急度タイムラインが終了した後にパイプライン DRI によって承認されます。
- テストは長期検疫に入ります。
- 3 ヶ月の削除カウントダウンが始まります。
マージ後の責任：
- 根本原因を調査する。
- 毎週 Issue に進捗を更新する。
- 3 ヶ月以内に解決または削除する。
テストが検疫される仕組み
テストは自動検出と手動特定を通じて検疫のために特定されます：
自動プロセス
自動フレーキーテストレポート - 最も影響の大きいフレーキーテストファイルを特定し、feature_category メタデータに基づいて Engineering Manager に割り当てられた検疫マージリクエストを自動的に作成します。詳細についてはフレーキーテスト：トップフレーキーテストファイルのレポートを参照してください。
これらのシステムの仕組みの詳細については、フレーキーテスト：検出と追跡を参照してください。
手動特定
パイプライン DRI または他のチームメンバーが繰り返しの失敗を特定し、Test Failure Issues プロジェクトの関連 Issue を使用してテストを手動で検疫します。
前提条件
テストを検疫する前に、関連する Issue が必要です。テスト失敗とフレーキー Issue は、スケジュールされたパイプラインでテストが失敗すると自動的に作成されます。バグの欠陥などの Issue は手動で作成されることがあります。
パイプラインジョブは失敗したテストを再試行します。テストが再び失敗すると、テスト失敗 Issue が更新（見つかった場合）または作成されます。エンドツーエンドテストパイプラインで環境の問題が見つかった場合は、代わりにテスト環境 Issue が提起されます。
Test Failure Issues プロジェクトでテスト失敗 Issue を手動で作成することもできます。
Issue には以下が含まれていなければなりません：
- 正しい
group::*ラベル（例：group::code_review）。失敗したパイプラインテストによって作成された失敗 Issue の場合、これらのラベルはラベラーによって自動的に適用されます。 - 失敗したパイプラインまたはジョブへのリンク。
- スタックトレースと失敗パターン。
~"failure::flaky-test"ラベル。
フレーキーテストの検出と追跡
テストを検疫する前に、フレーキーまたは失敗として特定されていなければなりません。GitLab は自動化されたシステムを使用してテスト失敗を検出・追跡します。
フレーキーテストがどのように検出、追跡、報告されるかの完全な情報については、フレーキーテストハンドブックページを参照してください。
主要システム：
- 自動フレーキーテストレポート（推奨）：最も影響の大きいフレーキーテストファイルを特定し、検疫マージリクエストを作成する
- テスト失敗 Issue（非推奨）：CI パイプラインでテストが失敗すると自動的に Issue を作成・更新する
これらのシステムは、どのテストに注意が必要かを特定することで検疫プロセスの基盤を提供します。
検疫ライフサイクル
緊急度と失敗テストを解決する能力に基づいて、適切な検疫タイプを選択してください。 ファスト検疫は迅速なマージのために専用リポジトリの別ファイルを使用し、長期検疫は GitLab コードベース内のテストメタデータを直接変更します。
検疫フェーズの期間
| フェーズ | 期間 | 必要なアクション |
|---|---|---|
| ファスト検疫 | 最大 3 日 | 修正、削除、または長期に変換 |
| 長期検疫 | 最大 3 ヶ月 | 調査と解決 |
| 削除警告 | 1 週間 | 最後の解決機会 |
| 自動削除 | 3 ヶ月後 | テストが恒久的に削除される |
ファスト検疫
以下の場合にファスト検疫を使用してください：
- テスト失敗が重要な開発作業をブロックしており、即座の検疫が必要な場合。
- 根本原因が既知または容易に特定可能な場合。
- 3 日以内に更新を提供することにコミットできる場合。
プロセス：
即座のアクション：
- ファスト検疫プロセスに従う
- Test Failure Issues プロジェクトの関連テスト失敗 Issue を正しいステージとグループラベルで更新する
最新のファスト検疫ファイルで失敗したジョブを再実行する：
- RSpec テスト（ユニット / 統合 / システム）：
retrieve-tests-metadataジョブを再トリガーし、失敗した RSpec ジョブを再試行する。単にジョブを再起動しても新しいファスト検疫の更新は反映されない。 - E2E テスト：単に失敗した E2E ジョブを再試行する - E2E テストは自動的に最新のファスト検疫ファイルをダウンロードする。
- 代替手段：新しいパイプラインを実行すると、すべてのテストタイプで最新のファスト検疫が反映される。
- RSpec テスト（ユニット / 統合 / システム）：
3 日以内に（ファスト検疫の期待）：
- オプション A：フレーキーテストの修正を実装する
- オプション B：テストを完全に削除する（他のテストと重複している場合またはフレーキーさを修正できない場合）
- オプション C：調査によって問題がより複雑であることが明らかになった場合は、更新されたタイムラインで長期検疫に変換する。
ファスト検疫をマージした後：
- 永続的な検疫を作成するための手順を含む自動リマインダーコメントを受け取る
長期検疫 MR がマージされた後：
- テストがデフォルトブランチのみで失敗していた場合は、先に作成したファスト検疫 MR をリバートする
- テストがテスト環境で失敗していた場合は、ファスト検疫を削除する前に長期検疫が必要な環境に到達するまで待つ
- 長期検疫 MR でテスト失敗 Issue を更新する
重要な注意事項：
- ファスト検疫は 3 日以内に更新を提供することにコミットする
- 3 日のタイムラインを守れない場合は、常に長期検疫に変換する
- ファスト検疫されたテストはデフォルトではローカルで引き続き実行される
- ファスト検疫されたテストは安定ブランチを含むすべてのブランチに適用される（例：
17-6-stable-ee） - ファスト検疫されたテストは ~“pipeline:run-flaky-tests” ラベルを適用することでマージリクエストで無視できる
⚠️ 警告：ファスト検疫ファイルはスケジュールされたパイプラインによって毎週日曜日の午前 10 時（UTC）に自動的にクリアされます。永続的な検疫または修正でフォローアップしてください。そうしないと、テストが再び失敗し始める可能性があります。
長期検疫
以下の場合に長期検疫を使用してください：
- 根本原因が不明で広範な調査が必要な場合。
- この特定のテストのために即座に利用可能な帯域幅がない場合。
- 調査が 3 日以上かかる見込みの場合。
長期検疫を使用するには、適切なメタデータを含む検疫マージリクエストを作成してください。技術的な実装の詳細（RSpec 構文、Jest 構文、メタデータタイプ）については、テストの検疫（開発者ドキュメント）を参照してください。
長期検疫の最大期間は 3 ヶ月（3 マイルストーンまたはリリース）です。所有者または Engineering Manager は、検疫通知システムによってテストが削除されることを通知されます。検疫クリーンアップシステムは、パイプライン DRI が 1 週間以内に対応するための削除マージリクエストを作成します。
テストの検疫解除
前提条件
テストを検疫解除する前に、以下のいずれかが真であることを確認してください：
- テストが一貫してパスしており（ローカルで 100 回以上）、根本原因が特定されて修正されている。
- テストが削除またはより良いカバレッジに置き換えられている。
検疫解除後 1 週間テストを監視する計画も必要で、失敗が発生した場合はすぐに再検疫することにコミットしてください。
手順
テストを検疫解除するには：
- テストを複数回実行して失敗なしにローカルで修正を確認する。
- マージリクエストを作成する：
- テストから
quarantine: 'issue-url'メタデータを削除する。 - 元の検疫 Issue にリンクする。
- 確認の証拠を含める。
- テストから
- マージリクエストがマージされた後、1 週間テストを監視する：
#master-brokenで失敗を監視する。- 新しいレポートのためにテスト失敗 Issue を確認する。
- 必要に応じてすぐに再検疫できるよう準備する。
- 1 週間の安定した実行後、検疫 Issue をクローズする：
- 根本原因と修正を文書化する。
~"quarantine::resolved"ラベルを追加する。
テストが再び失敗した場合
検疫解除されたテストが再び失敗した場合：
- ファスト検疫を使用してすぐに再検疫する。
- 新しい失敗情報で元の Issue を更新する。
- テストが以下のどれかであるべきかを再評価する：
- より低いテストレベルに移動する。
- 完全に削除する。
- より深い調査の対象にする。
テストが 3 回以上検疫された場合：
- テストは恒久的な削除の候補です。
#g_test_governanceで Test Governance チームと議論する。- 代替テストアプローチを検討する。
オーナーシップと説明責任
検疫されたテストを誰が所有するか
オーナーシップは feature_category によって決定されます。各フィーチャーカテゴリは特定のエンジニアリンググループにマッピングされており、そのグループはフィーチャーカテゴリを持つすべてのテストに対して責任を持ちます。
オーナーシップの責任
テストが検疫された場合：
- 48 時間以内に確認する。
- 根本原因を調査する。
- 解決のタイムラインを提供する。
- 毎週 Issue に進捗を更新する。
- 3 ヶ月以内に解決または削除する。
オーナーシップを維持しない場合：
- テストは 3 ヶ月後に自動的に削除されます。
- チームのテスト健全性メトリクスが影響を受ける可能性があります。
- 繰り返しの問題は Test Governance の介入が必要になる場合があります。
自動クリーンアッププロセス
3 ヶ月の削除タイムライン
- 1〜2 ヶ月目：アクティブな検疫期間。チームは調査と解決が期待されます。週次進捗更新が推奨されます。
- 3 ヶ月目：最終警告期間。テストオーナーに 1 週間前の事前通知が送られます。削除マージリクエストが作成されてチームに割り当てられます。これが解決または延長を正当化する最後の機会です。
- 3 ヶ月後：自動削除。テストはコードベースから恒久的に削除されます。削除の注記と共に検疫 Issue がクローズされます。チームに削除が通知されます。
通知プロセス
検疫ライフサイクル全体を通じて、オーナーは自動通知を受け取ります：
- 週次リマインダー：テストが検疫中の間、進捗更新を促すため。
- 削除 1 週間前：削除マージリクエストへのリンクを含む最終警告。
- 削除時：テストが削除されたことの通知。
削除マージリクエストは：
- 関連する Engineering Manager またはコードオーナーに割り当てられる。
- メンションでタグ付けされる。
- パイプライン DRI による手動承認が必要（半自動プロセス、完全自動ではない）。
- 解決または延長を正当化する最後の機会を提供する。
検疫レポート
可視性と説明責任を維持するために：
- 週次サマリー：現在の検疫ステータスとテスト解決の奨励を含む、エンジニアリングチームへの週次サマリーが送られる。
- 月次ロールアップ：テスト健全性メトリクスに関する上級管理職への月次ロールアップが提供される。
- チームダッシュボード：フィーチャーカテゴリ別にチームの検疫されたテストを追跡するために利用可能。
これらのレポートは、検疫がバックログではなく一時的な状態であることを確保するのに役立ちます。
詳細については、検疫改善イニシアチブエピックを参照してください。
特殊なケース
環境固有の問題
ライブ環境テスト失敗の場合：
- E2E テストにのみ適用される
- インフラチームの関与が必要です。
- 異なる SLA の期待が適用されます。
バックポートサポート（安定ブランチ）
ファスト検疫は安定ブランチにも適用されますが、安定ブランチへの長期検疫がマージされるまでパイプラインをブロック解除するためにのみ使用してください。
ツールとリソース
ファスト検疫ツール
fast-quarantine リポジトリは即座の検疫のためのマージリクエスト作成を自動化します。
フレーキーテストの追跡とダッシュボード
フレーキーテストの追跡システム、メトリクス、ダッシュボードについては、フレーキーテストハンドブックページを参照してください。
用語集
- テスト失敗 Issue：テストがパイプラインで失敗すると提起される失敗 Issue。手動で作成することもできます。テスト失敗 Issue プロジェクトを参照してください。
- 検疫マージリクエスト：テストパイプラインの実行で無視されるようにテストを検疫するマージリクエスト。メタデータには失敗のタイプとテスト失敗 Issue が含まれます。
- フレーキーテスト：十分な回数再試行すれば最終的にはパスするが、時々失敗する信頼性の低いテスト。フレーキーテストハンドブックページを参照してください。
関連トピック
- トップフレーキーテスト：レポート - トップフレーキーテストが自動的に検出・報告される仕組み
- 検疫改善イニシアチブエピック - 検疫改善プロジェクトの完全なコンテキスト
ヘルプを得る
- プロセスの質問：
#g_test_governance- Test Governance グループ - 一般的な質問：
#s_developer_experience- Developer Experience ステージ - 技術的なヘルプ：
#development- 一般的な開発ヘルプ - 緊急の問題：
#master-broken- 即座のパイプラインの問題 - テストオーナーシップの質問：フィーチャーカテゴリのマッピングを確認し、関連チームチャンネルで質問するか、
#g_test_governanceにエスカレーションする
