マージリクエストの役割と責任
マージリクエストの役割と責任
レビュアー
GitLab データチームのすべてのメンバーは、同僚やコミュニティのコントリビューターによるマージリクエストのコードレビューを行うことができ、また、それを奨励しています。 マージリクエストをレビューしたい場合は、誰かに割り当てられるのを待つこともできますが、オープンなマージリクエストの一覧を見て、フィードバックや質問を残すことも大歓迎です。
すべてのチームメンバーがすべてのマージリクエストをレビューできますが、マージリクエストを 承認 する権限はコードオーナーに限られます。
レビュアーの責任は以下のとおりです。
- 技術的な実装をレビューする
- コードがビジネス目標を達成することを確認する
- 作成されたデータモデルのデータ品質を確認する
コードオーナー
コードオーナーシップは、プロジェクトメンバーをプロジェクト内の特定のフォルダやファイルに結び付ける GitLab の機能です。「このコードについて誰に聞けばよいか」「このコードへの変更を誰がレビューすべきか」という問いに答えるためのものです。
各コードパスに割り当てるコードオーナーの人数は、十分に対応できる体制と、明確なオーナーシップの維持を両立させる必要があります。コードオーナーには、変更を自信を持って評価するため、担当分野の 深い知識 が必要です。私たちは、チームの規模よりも分野の専門知識を優先します。コードオーナーは、変更が技術的に適切であり、私たちの基準に沿っているかを評価できなければなりません。
一般的な目安として、比較的単純なコード（dbt モデルなど）には多めのコードオーナー（3 〜 5 人）を割り当てることで、レビューを依頼しやすくし、分担できます。専門知識を要する複雑なコード（データ抽出パイプラインなど）では、コードオーナーを少人数（2 〜 3 人）にすることで、分野の専門家による入念で質の高いレビューを確保できます。
コードオーナーは、以下を行います。
- コードに関する質問に答える最初の窓口となる
- コードの品質に責任を持つ
- コードが生み出す結果に責任を持つ
- MR をレビューし、マージリクエストを承認する
コードオーナーになる方法
- 希望するオーナーシップの変更を含む、
CODEOWNERSファイルへの MR を作成します- MR 本文で、その責任を引き受ける準備ができている理由を説明します。
- 最近行った MR レビューの具体例を示します。ごく単純な変更を加える MR もよいですが、そうした MR のレビューだけを根拠にしないでください。
- 参加したい分野をすでに担当している、ほかのコードオーナーと協力します。
コードオーナーになるにあたり、以下の要件を考慮してください。
- 対象分野について高度な理解があること。
- 自分が作成した MR が、大幅な変更を求められることなく、一貫してレビュアーとメンテナーのレビューを通過していること。
- 自分がレビューした MR が、大幅な追加変更を求められることなく、一貫してメンテナーのレビューを通過していること。
メンテナー
データチームの各プロジェクトにおけるメンテナーは、特定の役職を指すものではありません。 データチームは、メンテナーの責任について Engineering 部門が定めた先例に従います。 すべてのデータチームのプロジェクトには少なくとも 1 人のメンテナーがいます。ほとんどのプロジェクトには複数人がおり、Analytics などの一部のプロジェクトでは、dbt とオーケストレーションにそれぞれ別のメンテナーがいます。
メンテナーの責任は、以下を確実に行うことです。
- データチームのプロセスが守られていることを確認する
- MR がデータチーム全体のアーキテクチャ、手順、プロセスと矛盾しないことを確認する
- MR の最終レビューを行う
データチームのメンテナーになる方法
メンテナーになるためのガイドラインはありますが、具体的なルールはありません。 メンテナーには、GitLab Data の各プロジェクトのコードベースに対する高度な理解が必要です。 プロジェクトのメンテナーに応募する前に、コードベースの感覚を十分につかみ、1 つ以上の分野の専門知識と、私たちのコーディング基準への深い理解を身に付けてください。以下の両方の記述が当てはまると感じるなら、メンテナーになる準備ができているかもしれません。
- すでに複数の対象分野でコードオーナーになっている
- 自分がレビューした MR が、大幅な追加変更を求められることなく、一貫してメンテナーのレビューを通過している
- 自分が作成した MR が、大幅な変更を求められることなく、一貫してレビュアーとメンテナーのレビューを通過している
これらの主観的な要件を満たしている場合、自分をメンテナーに追加する手順は以下のとおりです。
- 関連するプロジェクトで、「Add
as project maintainer」というタイトルの Issue を作成します - 以下の内容を Issue に記載します。
- メンテナーの責任を引き受ける準備ができている理由
- メンテナーとして担当する範囲（プロジェクト全体、dbt、python など）
- 準備ができていることを示すと考える、最近作成・レビューした MR
- Issue を作成したら、ほかのすべてのメンテナーにタグを付けます
- 却下された場合は Issue を閉じ、再応募まで少なくとも 3 ヶ月間、マネージャーと協力します
- 承認された場合は、チームページの自分の項目にメンテナーとしての担当を追加する MR を作成します
- MR をマネージャーにアサインし、関連するプロジェクト（Infrastructure、Analytics など）と分野（dbt、Airflow など）の既存のメンテナーにメンションします。
- 既存のメンテナーから重大な異議がなければ、新しいメンテナーの誕生です!
- プロジェクトのオーナーが、そのプロジェクトでの権限を引き上げます
マージリクエストのワークフロー
すべての MR は、該当する MR テンプレートに従います。レビューの準備ができたら、コードオーナーにレビューをアサインします。コードオーナーが MR を承認すると、メンテナーがマージできます。コードオーナーがメンテナーを兼ねている場合は、同じ人でもかまいません。そうでない場合は、MR でメンテナーにタグを付け、最終レビューとマージを依頼します。
マージリクエストの承認要件
品質とセキュリティのため、すべての MR には複数のチームメンバーが関与し、マージ前に承認を受けることを求めます。デフォルトでは、CODEOWNER ファイルで承認の要否と承認者を定めています。ただし、ファイルやフォルダが CODEOWNER ファイルに記載されていない場合、承認を受けず、ほかのチームメンバーの関与もないまま MR をマージできてしまいます。これを防ぐため、このハンドブックのセクションに記載された基準を満たす GitLab-Data グループ内のプロジェクトには、以下の 2 つの設定を適用する必要があります。
注として、Approvals required のプロジェクト設定は、CI 変数 $CI_MERGE_REQUEST_APPROVED を正しく動作させるための回避策でもあります。詳細はこちらの Issueを参照してください。
5d840611)
