MR のマージ準備

このハンドブックページでは、MR をアナリティクスエンジニアにアサインする準備とマージの準備のために必要なステップを説明します。

MR を準備するためのステップ

アナリティクスエンジニアによるレビューと最終的な作業のマージを迅速に行うために、アナリティクスエンジニアをレビューにタグ付けする前に実施できるステップを紹介します。これらのステップを完了する前にヘルプが必要な場合は、遠慮なく早めに連絡してください！追加のサポートが必要な場合、レビューに追加の時間がかかる場合があります。

テンプレートが完全に記入されているか確認する

MR のレビューが遅くなる主な原因の一つは、テンプレートが不完全であることです。このページは、できるだけ多くの MR テンプレートを快適に記入できるよう支援し、レビュープロセスを迅速化することを目的としています。MR テンプレートの詳細については、MR テンプレートを理解するセクションをご覧ください。

変更をビルドする

「Build Changes」はパイプラインの CI ジョブの一つです。知っておくべき CI ジョブの詳細についてはこちらをご覧ください。MR がマージされる前に、「Build Changes」を実行し、成功することを確認する必要があります。

データをテストできるようにクローンを自分自身に付与する

「build changes」ジョブが成功したら、作成された MR データベースへのクローンを自分自身に付与できます。これにより、MR の変更をテストできるようになります。このステップはデータベースに不正確な情報を追加しないようにするために時間を節約するために重要です。新しいテーブルをデータベースにマージするリクエストを行う前に、変更をテストするためにクローンを自分自身に付与する必要があります。

クローンの付与方法については、こちらの CI ジョブページで詳細を確認できます。

権限は本番環境から複製されるため、新規テーブルを作成している場合、「grant clones」CI ジョブを使用してアクセスすることができません。データエンジニアにアクセスを依頼する必要があります。上のパラグラフにリンクされている CI ジョブページのグラントクローンセクションで、その方法についての詳細な手順を確認できます。

MR のテスト - SQL または Tableau で。期待通りに動作しているか確認する

テーブルへのアクセスが許可されたら、必ずテストしてください！Tableau または Snowflake でテストできます。アップデートのマージは時間がかかることがあります。変更のレビューだけでなく、データベースを更新した後に変更が反映されるまでの時間もかかります。

レポートテーブルの変更でコードに間違いがあっても他の誰にも悪影響がない場合でも、変更が不正確でそれを再変更する必要がある場合にはプロセスを遅らせてしまいます。MR の変更のレビューが完了し、変更が期待通りに動作しているというサインオフを行う場合、変更をテストしたことをコミットしていることになります。

MR を作成する前にすでに SQL/Tableau で変更をテストした場合、テストを最小限にすることができますが、Snowflake/Tableau から MR に転送した後でも、SQL が期待通りに動作しているかを再確認することをお勧めします。

既存のテーブルを更新している場合は行数を追加する

「Remote Testing」は、リモートテストの結果を記載する箇所です。これは、Tableau でこれらの変更をテストしたことの確認である場合があります。テストの結果をエクスポートしたスプレッドシートへのリンクを含める場合があります。例えば、変更前後の SQL コードの結果を比較するピボットテーブルなどです。

コードオーナーにこの MR をレビューのためにアサインする前に、「Row Count Test（行数テスト）」を含める必要があります。これは前のステップで記載された dbt テストの一つではなく、自分自身で実行する SQL クエリです。これはテーブルの本番バージョンと MR バージョンの行数を単純にカウントするものです。これは既存のテーブルを編集している MR のみに適用され、新規作成されたテーブルには適用されません。

この行数チェックは、誤って JOIN を間違えてしまい、テーブルの行数が大幅に増加または減少するケースを検出します。これは、dbt モデル変更のほぼすべての MR での標準的な慣例です。結果のテーブルをテンプレートのこのセクションに直接貼り付けることができます。

サンプル SQL コード

    SELECT
        COUNT(*) as row_count,
        'prod' as source
    FROM prod.your_schema.your_table_name

    UNION ALL

    SELECT
        COUNT(*) as row_count,
        'MR' as source
    FROM "your-mr-branch-name".your_schema.your_table_name

注意事項：MR テーブルの行数が本番環境よりも少ない場合は、MR データベースが本番環境より古い可能性があります。例えば、毎日更新されるテーブルで、MR が 3 日前のもので、最後に変更をビルドしたのが 3 日前であれば、テーブルの行数は同じになりません。変更を再ビルドし、新しいクローンを自分自身に付与することで修正できるはずです。詰まった場合はアナリティクスエンジニアに助けを求めることができます。

MR テンプレートを理解する

このセクションでは、新規レポートテーブルの作成や、prep、mart、fact、dimension、またはレポートレイヤーの既存カラムの更新に使用すべき「Dbt Model Changes」テンプレートを詳しく説明します。

以下は MR テンプレートのセクションごとの内訳です。画像の番号は画像下のテキストに対応しており、そのセクションを説明します。赤丸の数字は、特にレポートテーブルの各 MR において、あなた（MR の作成者）がアクションを取る必要があるセクションを示しています。

MR 1

「Closes」は、このマージリクエストがクローズする Issue を指します。通常、開発ライフサイクルでは、行うべき作業を説明する Issue が作成され、その後 MR が作成されて実施されます。その MR がマージされると、その Issue はクローズされる準備ができています。
- これ以外のユースケースがある場合があります。例えば、Tableau での変更が必要な Issue を作成し、MR がマージされると Issue がクローズされる準備ができていない場合（まだ Tableau での変更が必要だから）があります。これは問題ありません。テンプレートのこのセクションに MR がクローズする Issue を記載すると、MR がマージされると自動的にクローズされることを知っておいてください。
- MR にまだ Issue が関連付けられていない場合、Issue を作成することは、あなたが協力しているアナリティクスエンジニアにとって役立つかもしれません。彼らは Issue を使って作業について議論したり、レビュー会議を計画したり、その週のスケジュールに割り当てて適切に時間を確保したりできます。
テンプレートのスコープセクションでは、dbt での変更内容とその理由を説明する必要があります。詳細に書く必要はありませんが、作業に馴染みのない人が「何を」「なぜ」をすぐに理解し、レビューしてマージできるよう、このセクションを活用してください。
- ヒントとして、MR で GitLab Duo の「Explain Changes」ボタンが利用可能な場合はそれを使用できます。利用できない場合は、MR の変更タブの内容をコピーして貼り付け、変更内容の要約を依頼することができます。編集が必要な場合もありますが、取り組みを始める助けになるかもしれません。
dbt では、テストは .yml ファイルで設定された事前定義またはカスタムのチェックであり、モデルのデータを検証します。これらのテストは、null 値がないこと、行がユニークであること、参照整合性を維持していることなど、結果テーブルの特定の条件を自動的にチェックします。このアプローチにより、データ検証とモデルコードが分離され、データ品質と保守性を確保しやすくなります。
- dbt を使い始めたばかりの場合、テーブルにテストを追加する必要はほとんどないでしょう。MR をレビューするアナリティクスエンジニアが、関連するテストがあると思われる場合は提案します。モデルへのテストの追加について詳しくは、Trusted Data Framework ハンドブックページをご覧ください。
CI ジョブにより、MR のスコープに含まれるモデルと環境がビルドされます。「Changes」タブが MR のスコープを概説するため、このセクションはそのままにしておくことができます。まれに build_changes ジョブに含まれるもの以外に追加のモデルをビルドする必要がある場合は、ここで指定できます。追加のモデルを実行する必要がある場合は、custom_invocation ジョブ、または指定された SELECTION を持つ build_changes ジョブを使用できます。
MR がマージされる前に、「Build Changes」の実行、自身への「Grant Clones」、および Snowflake または Tableau でのリモートテストを実行する必要があります。
「Verify」セクションでは、加えた変更が期待通りの影響を与えていることを確認します。結果は以下に含めます。
行数の追加方法については、上の「行数」セクションを参照してください。既存のテーブルを更新している場合は、これをベストプラクティスとして常に実施してください。予期しない JOIN エラーを見逃してしまうことを防ぐことができます。
「Review」リストの一部のアイテムにアクションを取る必要があるかもしれません。答えが不明な場合は、アナリティクスエンジニアと協力してこのセクションを進めることができます。最もアクションが必要と思われるアイテムは以下のとおりです：
1. 変更が意図した通りに動作することを確認するために適切にテストしたことを確認します。
2. 変更をテストするために必要な CI ジョブを実行する必要があります。MR のマージを依頼する前に、変更がすべて正常にビルドされることを確認してください。
3. チームのスタイルガイドに従うよう最善を尽くしてください。General セクションが特に参考になります。アナリティクスエンジニアを MR のレビューにタグ付けすると、スタイルガイドに従ってコードをフォーマットする手助けもしてもらえます。
4. VS Code を使用している場合は、コードのリントを自分自身で実施することができ、自動フォーマットが提供されます。
5. MR をマージする前に、ダウンストリームの変更を考慮する必要があります。例えば、ダウンストリームで使用されているカラムを名前変更すると、データウェアハウスのダウンストリームテーブルが壊れる可能性があります。Tableau で使用されているカラムを名前変更すると、そのカラムを使用しているダッシュボードが壊れます（変更を元に戻さなければこのエラーを修正するのは難しい場合があります）。
コードオーナーとメンテナーはこのセクションをレビューし、レビューを完了したらアイテムにチェックを入れます。
MR を作成するときは、最初に自分自身にアサインすることが多いでしょう。これにより、開いている進行中の MR を追跡しやすくなります。
テストを完了し、変更がレビューの準備ができたら、変更したファイルのコードオーナーであるアナリティクスエンジニアに MR をアサインします。彼らが変更をレビューして承認したら、マージのためにメンテナーに MR をアサインします。
ラベルは MR の追跡に役立ちます。チームが GitLab 作業でラベルを使用している場合、同じラベルを MR に適用できます。

レビュワーのアサイン

MR を作成し、変更をテストして満足し、テンプレートをできるだけ記入し、アナリティクスエンジニアのヘルプが必要な場合は、レビュワーをアサインする時間です。レビュワーに関する公式ドキュメントはこちらです。公式のレビューワークフローに関する情報はこちらです。

通常プロジェクトでアナリティクスエンジニアと協力している場合は、まずその人に誰が MR をレビューすべきか聞くのが最善策です。通常一緒に作業しているアナリティクスエンジニアがいない場合は、MR の「reviewers」セクション（パイプラインのすぐ下）で、変更しようとしているテーブルのコードをオーナーする人を確認できます。

Reviewers

そのリストから誰でも選択し、MR の右サイドバーを使用してレビュワーとしてアサインできます。また、MR のコメントで「@reviewer さん、この MR に取り組んでいます。変更をテストし、できる限りテンプレートを記入しました。確認していただき、マージのために必要なことを教えてもらえますか」とメッセージを残すこともできます。

MR 作成のステップの一つで詰まっていて、誰に助けを求めればいいかわからない場合にも、ここを見ることができます。

レポートテーブルと上流テーブルの変更

アナリストとして MR を作成する際、いくつかの MR は他のものよりも簡単/迅速にレビューしてマージできることを理解しておくと役立ちます。これはコード変更の複雑さと場所によって異なります。

多くの変換とカスタムロジックを含む長大なレポートテーブルを作成した場合、アナリティクスエンジニアがこれらの変更をレビューするのに時間がかかります。サブクエリの代わりに CTE を使用し、コードにコメントと完全修飾カラム名を明確にラベル付けすることで、コードに馴染みのない人がより早く理解できるようになります。

アナリティクスエンジニアが MR にフィードバックをすることもあります。不整合を検出したり、スタイルの推奨事項を提案したりする場合があります。GitLab では、コードのフォーマット方法について一貫したスタイルガイドを使用しています。アナリティクスエンジニアはコードに対してスタイルガイドを満たすための提案をすることがあります。これにより、関係するすべての人にとって使いやすく保守しやすくなります。

レポートテーブル vs. Mart/Fact テーブル

mart/fact/dimension/prep テーブルへの変更と、レポートテーブルへの変更では、厳格さのレベルが異なります。前述の 4 種類のテーブルはクロスファンクショナルな唯一の信頼できる情報源（single-source-of-truth）のテーブルです。これらのテーブルは GitLab の多くの異なるレポートを駆動しており、これらのテーブルへの最小限の変更でも多くの異なるレポートやテーブルへのダウンストリームへの影響があります。したがって、これらのテーブルへの変更をマージするには、徹底的なテストと慎重なレビューが必要であり、コードの品質について最高水準が求められます。

一方、GitLab のデータチームはアナリストがレポートテーブルを作成・維持できるようにしたいと考えています。レポートテーブルはしばしば、Tableau ダッシュボードなどのレポート用に適切な形にデータを変換するデータ変換を含みます。Tableau ダッシュボードは、カスタム SQL を指定するよりも Snowflake のレポートテーブルを指定する方がパフォーマンスが向上します。

ダッシュボードで使用されているレポートテーブルを更新/作成している場合、多くの他のテーブル/レポートで使用されている mart テーブルを更新する場合よりも、レビュープロセスが迅速に進む可能性があります。アナリティクスエンジニアがレポートテーブルをレビューする際は、以下を確認します：

コードが読みやすい
コードが機能し、何も壊さない
冗長性がない
重要なビジネスロジックがない

GitLab では、すべての人が上流で使用できるビジネスロジックをレポートテーブルに保持することを避けています。仮定の例を挙げてみましょう。レポートテーブルがあり、そのカラムの一つが「Customer Size」だとします。このカラムでは、顧客を「<$500」「$501-$1,000」「>$1,000」の収益バンドにグループ化しています。

次に、あなたの部門全体が一般的にこの方法で顧客をグループ化したいとします。収益に関するすべてのレポートテーブル/Tableau レポートにこの「Customer Size」CASE ステートメントを作成する代わりに、prep または fact テーブルの上流でそのグループ化を作成することが理にかなっています。そうすれば、そのカラムはベーステーブルから構築されたすべての他のテーブルに流れます。

これは、会社が成長して「Customer Size」が報告されるすべての場所で「<$1,000」「$1,001-$5,000」「>$5,000」のサイズでグループ化する必要が生じた場合にも大いに役立ちます。これらの理由から、MR でアナリティクスエンジニアからカラムの一つがビジネスロジックのように見えるというフィードバックを受け、上流に移動させることを提案される場合があります。そのような変更は通常、アナリティクスエンジニアが引き継いだり、手助けしてくれたりするものです。

MR 準備のためのその他の役立つリソース

DBT ガイド: https://handbook.gitlab.com/handbook/enterprise-data/platform/dbt-guide/ スタイルガイド: https://handbook.gitlab.com/handbook/enterprise-data/platform/dbt-guide/#style-and-usage-guide dbt 使用に関する一般的な役立つ情報: https://handbook.gitlab.com/handbook/enterprise-data/platform/dbt-guide/#general

最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)

ページのソースコードを見る - ページの編集 - please contribute.