マージリクエストの役割と責任
マージリクエストの役割と責任
レビュアー
GitLab データチームのすべてのメンバーは、同僚やコミュニティコントリビューターのマージリクエストのコードレビューを実行することができ、また奨励されています。 マージリクエストをレビューしたい場合は、誰かが割り当てるのを待つこともできますが、オープンなマージリクエストのリストを閲覧してフィードバックや質問を残すことも大歓迎です。
すべてのチームメンバーがすべてのマージリクエストをレビューできますが、マージリクエストを承認する権限はコードオーナーに限定されていることに注意してください。
レビュアーの責任は以下のとおりです。
- 技術的な実装をレビューする
- コードがビジネス目標を達成していることを確認する
- 作成されたデータモデルのデータ品質を確認する
コードオーナー
コードオーナーシップは GitLab の機能で、プロジェクトメンバーをプロジェクト内の特定のフォルダーとファイルにリンクします。これは「このコードについて誰に聞けばいいか？」「このコードへの変更を誰がレビューすべきか？」という質問に答えることを目的としています。
各コードパスに割り当てられるコードオーナーの数は、十分なカバレッジを確保することと明確なオーナーシップを維持することのバランスを取る必要があります。コードオーナーは変更を自信を持って評価するために割り当てられたドメインの深い知識を持っている必要があり、チームの規模よりもドメインの専門知識を優先します。コードオーナーは変更が技術的に健全で私たちの標準に沿っているかどうかを評価できる必要があります。
一般的なガイドラインとして、複雑でないコード（dbt モデルなど）はより多くのコードオーナー（3〜5 人）に対応でき、レビューをよりアクセスしやすく分散させることができます。専門知識を必要とするより複雑なコード（データ抽出パイプラインなど）は、ドメインエキスパートからの徹底的で高品質なレビューを確保するために、より少ないコードオーナーのグループ（2〜3 人）から恩恵を受けます。
コードオーナーは以下を行います。
- コードに関する質問への最初の連絡窓口となる
- コードの品質のオーナーシップを持つ
- コードが生成する結果のオーナーシップを持つ
- MR レビューを実行してマージリクエストを承認する
コードオーナーになる方法
CODEOWNERSファイルに行いたいオーナーシップの変更を含む MR を作成します。- MR 本文で、その責任を引き受ける準備ができている理由を説明します。
- 実行した最近の MR レビューの具体的な例を使用します。非常にシンプルな変更を導入する MR も良いですが、唯一のレビューソースであるべきではありません。
- すでにそのエリアをカバーしている他のコードオーナーと協力します。
コードオーナーになるために考慮すべき要件:
- 特定の対象分野について高度な理解を持っている必要があります。
- 作成した MR がレビュアーとメンテナーのレビューを通じて大幅な変更なく一貫して通過している必要があります。
- レビューした MR がメンテナーのレビューを通じて大幅な追加変更なく一貫して通過している必要があります。
メンテナー
データチームプロジェクトのメンテナーは、職位と同義ではありません。 ここでは、データチームはエンジニアリング部門がメンテナーの責任に関して設定した先例に従います。 すべてのデータチームプロジェクトには少なくとも 1 人のメンテナーがいますが、ほとんどは複数のメンテナーがおり、一部のプロジェクト（Analytics など）には dbt とオーケストレーションのための別々のメンテナーがいます。
メンテナーの責任は以下を確保することです。
- データチームのプロセスが守られている
- MR がより広いデータチームのアーキテクチャ、手順、プロセスと競合していない
- MR の最終レビュー
データチームのメンテナーになる方法
メンテナーシップのガイドラインはありますが、具体的なルールはありません。 メンテナーは GitLab データプロジェクトのコードベースについて高度な理解を持っている必要があります。 プロジェクトのメンテナーシップを申請する前に、コードベースに対する十分な感覚、1 つ以上のドメインにおける専門知識、および私たちのコーディング標準についての深い理解を得る必要があります。以下の両方のステートメントが真であると感じる時、メンテナーになる準備ができているかもしれません。
- すでに複数の対象分野でコードオーナーである
- レビューした MR が大幅な追加変更なくメンテナーのレビューを通じて一貫して通過している
- 作成した MR が大幅な変更なくレビュアーとメンテナーのレビューを通じて一貫して通過している
これらの主観的な要件が満たされた場合、メンテナーとして自分を追加するためのプロセスは以下のとおりです。
- 関連するプロジェクトで「Add
as project maintainer」というタイトルで Issue を作成します - 以下の項目のドキュメントを Issue に追加します。
- メンテナーの責任を引き受ける準備ができている理由を説明する
- メンテナーシップのスコープを説明する（プロジェクト全体、dbt、Python など）
- 準備ができていることを示すと思う最近の MR の作成とレビュー
- Issue が作成されたら、他のすべてのメンテナーにタグを付けます
- 拒否された場合は Issue をクローズして、再申請する前に少なくとも 3 ヶ月間マネージャーと協力します
- 承認された場合は、チームページのエントリにメンテナーシップを追加する MR を作成します
- MR をマネージャーに割り当て、関連するプロジェクト（インフラ、アナリティクスなど）とエリア（dbt、Airflow など）の既存のメンテナーに言及します
- 既存のメンテナーが重大な異議を持たない場合は、新しいメンテナーが誕生します！
- プロジェクトのオーナーがプロジェクト上の権限を高めます
マージリクエストワークフロー
すべての MR は適用可能な MR テンプレートに従います。MR がレビューの準備ができたら、コードオーナーにレビューを割り当てます。コードオーナーが MR を承認したら、MR はメンテナーによってマージできます。コードオーナーもメンテナーである場合は同一人物でも構いません。そうでない場合は、最終レビューとマージを求めてメンテナーが MR にタグ付けされます。
マージリクエストの承認要件
品質とセキュリティのため、すべての MR が複数のチームメンバーが関与してマージ前に承認されることを要求します。デフォルトでは CODEOWNER ファイルが承認が必要かどうかと誰によって必要かを設定します。ただし、ファイルやフォルダーが CODEOWNER ファイルに存在しない場合でも、承認なしや他のチームメンバーの関与なしに MR をマージできます。このハンドブックセクションで言及された基準を満たす場合、GitLab-Data グループ内のプロジェクトには以下の 2 つの設定を適用する必要があります。
注: Approvals required プロジェクト設定は、CI 変数 $CI_MERGE_REQUEST_APPROVED が正しく機能するための回避策でもあります。詳細はこの Issue を参照してください。
