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が見つからない場合
- ガイドに従ってQA失敗のデバッグを続けます
- Developer Experienceステージ - オンコールDRIまたはDistribution SETに連絡を取ります

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

プロセス:

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

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