Content last updated 2026-07-15

Distributionグループのテストプラットフォーム

概要

このページの目的は、Distributionグループにおける既存の品質エンジニアリング活動を文書化することです。

品質作業はepic#9057で追跡されています。このエピックには、Distributionグループにおける品質をより良くサポートするために取り組む必要がある大規模なイニシアチブが一覧されています。

GitLab QAはDistributionプロジェクトでGitLabが期待通りに動作することを検証するために使用されています。

プロジェクト	テスト種類	スケジュール
GitLab Omnibus	フル	QAミラーパイプラインがトリガーされる
GitLab Charts	サニティ	マージリクエストで自動実行およびデフォルトブランチに対してスケジュール実行
GitLab Charts	フル	マージリクエストで手動トリガー
GitLab Operator	スモーク	マージリクエストで自動実行
GitLab Operator	フル	手動トリガー
Reference Architecture Tester	フル	手動トリガーおよびFIPS QAナイトリー

開発用にGitLab QAをローカルで実行する方法については、GitLab QAの実行を確認してください。

オープン中のパイプライントリアージIssueで失敗を検索するか、メインGitLabプロジェクトでspecの名前を検索します
- Allureレポートが利用可能な場合: レポートリンクをクリック -> プロダクト欠陥 -> 失敗したspecを選択 -> 失敗Issueをクリック。デモ
- 一部のspecには、異なるスタックトレースを持つ複数のQA失敗Issueが存在する場合があります。その場合は、ジョブからの失敗したスタックトレースをIssueにリストされているものと比較してください。
同じエラーのIssueが見つからない場合
- Distribution チームが QA 失敗のトリアージとデバッグを所有します。ガイドに従って失敗のデバッグを続けてください
- 重大な問題では最後の手段として、Developer Experience の #s_developer_experience に連絡してください

Distributionチームはバグ優先順位付けを協力して行い、チームの現在の稼働状況に基づいてマイルストーンあたり少なくとも6つのバグをクローズすることを目指しています。マイルストーンあたりのバグ数は次のissue#1100で再検討されます。

プロセス:

チームが新しい計画Issueを作成します
Distribution チームメンバーがバグ優先順位付けテンプレートを使用して新しい Issue を作成します
Distribution チームメンバーがDistribution Issuesを使用してオープンなバグを確認します
- 重大度ラベルがないバグに重大度ラベルを追加します
- 優先順位付けガイドラインに従ってオープンなバグを確認します
Distribution チームがチーム計画 Issue でマイルストーンで考慮する 6 つのバグを提案します
四半期末に:
- Distribution チームメンバーがオープンなバグのDistribution Issuesメトリクスを確認します
- 調査結果を Distribution チームと共有します
- Distributionはプロセスを調整すべきかどうかを議論します

品質チームはクアッドプランニングプロセスに従って、クアッドプランニング用のオープンなIssueを確認します。