DEX コードレビューガイドライン
概要
コードレビューはすべてのマージリクエストで必須です。ここで概説するコードレビューガイドラインに精通し、それに従ってください。
これらのガイドラインは、誰があなたや、あるいはコミュニティメンバーのマージリクエストをレビュー、承認、マージする必要があるかも記述しています。また、チームメンバーが守るべきレビュー応答 SLO についても記述しています。
価値観
GitLab のすべてのレビュアーは、私たちのレビュアーの価値観 を目指す必要があります。
マージリクエストをレビュー、承認、マージしてもらう
受入チェックリスト
このチェックリストは、マージリクエスト（MR）の作成者、レビュアー、メンテナーに対し、品質、パフォーマンス、信頼性、セキュリティ、可観測性、保守性に対する高インパクトリスクについて変更が分析されたことを確認することを促します。
ソフトウェアエンジニアリングではチェックリストの使用が品質を向上させます。このチェックリストは、GitLab Marketing コードベースへの貢献者のスキルをサポートし強化するためのシンプルなツールです。
マージリクエスト提出時のチェックリスト
- マージリクエストテンプレートを完成させる
- 構築中はマージリクエストの先頭に
Draft:を付けてください。 - マージリクエストテンプレートのすべてのフィールドが適切に埋められていることを確認してください。 包括的な説明を提供する
- 何が変更されたか、なぜ変更が必要だったか、それがどのように問題や機能要求に対処するかを明確に説明してください。
- 該当する場合、行ったリファクタリングやアーキテクチャ上の決定について言及してください。
- 構築中はマージリクエストの先頭に
- 関連 Issue をリンクする
- 適切な構文（例: related #1234）を使用して、関連する Issue、チケット、ユーザーストーリーを参照してください。 参照される Issue が正しくタグ付けされ、最新であることを確認してください。
- テスト手順をドキュメント化する
- ローカルまたはテスト環境で変更をテストする方法について、明確で段階的な手順を提供してください。
- テストに必要な特別な設定、テストデータ、前提条件について言及してください。
- 自動テストが含まれる場合、その場所と実行方法を指定してください。
- デプロイ手順
- 必要なスクリプト、コマンド、設定を含むデプロイプロセスを詳述してください。
- 更新または再起動が必要な依存関係やサービスについて言及してください。
- QA と検証
- 検証に使用される環境（例: ローカル、レビューアプリ、本番環境）を指定して QA プロセスを概説してください。
- 期待される結果を含む、テストすべき主要なシナリオとエッジケースをリストしてください。
- デプロイ後の検証
- デプロイ後に本番環境で変更を検証するための計画を提供してください。
- 潜在的な問題を監視するためのモニタリングやロギングを含めてください。
- 問題発生時のロールバック計画を詳述し、変更を安全に元に戻すための手順を指定してください。
- フィードバックとレビューを依頼する
- マージリクエストのタイトルから
Draft:を削除するか、ドラフトのままにしている理由を説明してください。 - コードレビュー、QA、その他必要な承認のために関連するチームメンバーをメンションしてください。
- スムーズなレビュープロセスのため、コメントや変更要求に迅速に対応してください。アサインされた担当者は、フォローアップ Issue を作成し追跡し、それらが適時に完了するように責任を持ちます。
- マージリクエストのタイトルから
レビュアー
GitLab のエンジニアは全員、同僚やコミュニティ貢献者のマージリクエストに対してコードレビューを行うことができ、奨励されています。マージリクエストをレビューしたい場合、誰かがアサインしてくれるのを待つこともできますし、オープンなマージリクエストの一覧を閲覧して、フィードバックや質問を残すこともできます。すべてのエンジニアがすべてのマージリクエストをレビューできる一方、マージリクエストを 受け入れる 能力はメンテナーに限定されていることに注意してください。
マージリクエストのレビュアーを見つける方法:
- GitLab Digital Experience チームメンバー のリストを確認する。
- Reviewer Roulette を活用する。これは現在チームで利用可能なメンテナーとレビュアーの提案を出してくれます。提案は MR の変更に関するコメントとしてリストされます。Reviewer Roulette は Buyer Experience プロジェクトでのみ利用可能です。
レビューのターンアラウンドタイム
他人のブロックを解除することは常に最優先事項 なので、 レビュアーはマージリクエストをタイムリーにレビューすることが期待されます。 これによって他のタスクや優先順位に悪影響が及ぶ場合でも同様です。
そうすることで、コンテキストが記憶に新しいうちにマージリクエストに関わる全員が早く反復でき、貢献者の体験が大きく向上します。
レビュー応答 SLO
レビュー準備が整ったコードに迅速なフィードバックを保証するため、Review-response サービスレベル目標（SLO）を維持しています。
SLO は GitLab チームメンバーには適用されますが、より広範なコミュニティの貢献者には適用されません。
SLO は次のように定義されます:
Review-response SLO = （レビューが提供された時刻） - （MR がレビュアーにアサインされた時刻）
Digital Experience GitLab チームメンバーの SLO 値は 2 営業日です。
Review-response SLO の時間枠内でマージリクエストをレビューできないと思う場合は、できるだけ早く（最初のレビュー依頼を受けてから 36 時間以内）に作者にコメントで知らせ、別のレビュアーやメンテナーを見つけるのを手伝って、彼らがブロック解除されて作業を素早く進められるようにしてください。自分自身をレビュアーから外してください。
もちろん、休暇中で コミュニケーション を GitLab.com ステータス経由で行っている場合、作者はそれに気づき、 別のレビュアーを自分で見つけることが期待されます。
マージリクエスト作成者が
Review-response SLO よりも長くブロックされている場合、Slack でレビュアーにリマインドするか、
別のレビュアーを追加することは自由です。
期待値の管理
MR のレビュアーにアサインされ、Review-response SLO 内でそれに着手できない場合、作者に遅延応答を知らせる MR コメントを残す必要があります。可能であれば、作者がフィードバックを期待できる時期を示すか、代替のレビュアーを見つけるのを手伝う必要があります。
MR の作者として、Review-response SLO が満たされず、アサインされたレビュアーに連絡できなかった場合、別のレビュアーやメンテナーへの再アサインが必要です。
Code Owner 承認
一部の GitLab プロジェクトは、特定のファイルパスやタイプに対する承認を管理するために GitLab の CODEOWNERS ファイル機能 を使用しています。digital-experience/about.gitlab.com プロジェクトでは、職務分掌のベストプラクティスに従うため、CODEOWNERS 承認ルールに加えて MR 承認設定を組み合わせて使用 しています。このセクションでは、digital-experience/about.gitlab.com プロジェクトの CODEOWNERS 変更に対して適格な承認者を更新するプロセスを説明します。
CODEOWNERS ファイル 自体の Code Owner は、ファイル内のルールで管理されます。
