dbtのブランチ戦略: trunk-basedとrelease branchをどう使い分けるか

dbtはGitブランチを前提に環境とデプロイを結びつけるため、ブランチ戦略は品質・速度・リスクを左右します。

本稿ではtrunk-based（main中心）を基本に、release branchが必要となる条件と設計パターン、CI/テスト・スキーマ設計・選択子（state:modified）までを具体的に解説します。

前提と用語整理：dbtにおけるブランチと環境

dbtでは、Gitのブランチを「どのコードで実行するか」を決める一次の切り替え点にします。dbt Cloudではデプロイ用Environmentが1つのGitブランチにひも付き、ジョブはそのブランチのコードで実行されます。CLIでも同様に、チェックアウトしたブランチ上のdbtコマンドが実行対象です。

trunk-based（メインブランチ中心）は、変更を小さく・頻繁にmainへ統合し、PRで品質を担保する方式です。release branchは、ある時点の変更を束ねて“リリース単位”として固定化し、凍結・検証・段階的リリースやロールバックを容易にする方式です。

• trunk-basedの狙い: 小さな差分で継続的に出す（低リスク・短いリードタイム）
• release branchの狙い: 大きな変更や外部公開を伴う変更をまとめて管理（可視性・切戻し容易）
• dbtの安定機能: state:modified 選択、defer 実行、tests・contracts、PRビルド（dbt Cloud）

trunk-basedの実装手順（dbt Cloud/CLI共通）

基本は「featureブランチ → PRでレビューとCI → mainへマージ → mainで本番デプロイ」。PRのCIではslim CI（state比較）を使い、差分とその依存だけを高速に検証します。デプロイはmainブランチを参照する本番Environment/ジョブに集約します。

本番実行とPRビルドの差を最小化するため、deferで本番アーティファクト（前回のmanifest/Run Results）を参照し、未変更モデルの再ビルドを避けながら依存整合性を検証します。

• feature/* で実装。PR作成時に dbt build をslim CIで実行
• PRでtests（schema・data）、contracts、exposuresの影響をチェック
• mainへマージ後、main固定の本番ジョブで dbt build（state:modified+ で差分デプロイ）

trunk-basedの標準フロー（PR CI → mainデプロイ）

slim CIの最小例（CLI想定、PR時）

dbt deps
# 本番の前回成果物を参照（場所はS3/GCS/DBFS/ローカルなど運用に合わせる）
dbt build \
  --select state:modified+ \
  --state path/to/prod_artifacts \
  --defer

release branchを使う条件と設計パターン

日常運用はtrunk-basedで十分です。ただし次のような状況ではrelease branchが有効です。外部向けデータ共有やBIの公開に合わせた一括切替、規制や監査で“この版”の再現性が強く求められる、長時間のバックフィルやスキーマ移行を伴い段階的リリースを管理したい、繁忙期のコードフリーズが必要、など。

設計の要点は、release/* を切ったら必要最小限の変更だけを取り込み、PRレビュー・CIをreleaseブランチで行い、本番Environmentを一時的にreleaseブランチへ向けるか、カナリア用Environmentで先行適用→切替にします。hotfixはreleaseから切ってcherry-pickし、mainへback-mergeして乖離を抑えます。

• release/* は短命・目的限定で運用（長期固定は技術的負債化しやすい）
• バックフィルや移行は可能なら専用ジョブで分離し、releaseには最小限の制御だけ載せる
• 切替後は速やかにmainへ合流（back-merge）し、差分を解消

releaseブランチの基本オペレーション（例）

# 一時的なリリースブランチを作成
git switch -c release/2024w42

# 必要なPRのみマージ（スコープを最小化）
# ... code review / merge ...

# dbt Cloudの本番Environmentを一時的に release/2024w42 に向ける
# or カナリア用Environmentで先行適用

# ホットフィックス
git switch -c hotfix/bug-on-release release/2024w42
# 修正後、releaseへマージし、本番へ反映
# mainへback-mergeして差分を解消

スキーマと環境分離の作法（dev/stg/prodとブランチの関係）

dbtでは同一データベースでスキーマを分ける運用が一般的です。ブランチは“どのコードを走らせるか”、環境は“どこにデプロイするか”を分担させます。devではユーザごとのスキーマ、stg/qaでは共有スキーマ、prodは固定スキーマという分離が扱いやすいです。

ブランチ戦略と合わせ、スキーマ命名をtarget.nameやカスタムスキーマで一貫させましょう。expand/contractの移行では、旧カラムの残置期間を設け互換を保ちながらreleaseの有無に関わらず安全に進めます。

• devは user_プレフィックスで衝突回避、prodは安定名に固定
• seeds/snapshotsはタグ管理で環境ごと実行を制御
• exposuresやcontractsはprodで必ず有効化し、PRで検証

generate_schema_nameの一例（環境に応じてスキーマを分離）

{% macro generate_schema_name(custom_schema_name, node) -%}
  {% if target.name == 'prod' %}
    {{ custom_schema_name or 'analytics' }}
  {% else %}
    {{ target.name }}__{{ custom_schema_name or 'analytics' }}
  {% endif %}
{%- endmacro %}

CI/CDと品質ゲート：state選択子・defer・テストの組み合わせ

slim CIのコアはstate比較です。前回の本番アーティファクトと比較し、変更モデルとその下流のみをビルド・テストします。これにdeferを合わせることで未変更上流を“存在するものとして解決”し、PRビルドを高速化できます。

リリース運用時も、releaseブランチ上で同じ選択子・deferを使い、移行ジョブ（バックフィル）をタグで分離します。contractsとtests（unique/not_null/relationships）は必ずPRで通す設計にします。

• selectors.ymlでstate選択子を定義し再利用
• contracts: 互換性を壊す変更はexpand→両対応→contractで段階適用
• 移行系ジョブは tags: [migrate, backfill] などで分離実行

selectors.yml と実行例

# selectors.yml
selectors:
  - name: pr_modified
    definition:
      method: state
      value: modified
      children: true

# 実行例（PR CI）
dbt build --select @pr_modified --state path/to/prod_artifacts --defer

# 実行例（本番）
dbt build --select state:modified+ --state path/to/prod_artifacts

試験対策の要点と落とし穴

Analytics Engineer試験では、ブランチ戦略そのものよりも、PR中心の開発フロー、state/deferの使いどころ、contracts/testsでの品質担保、互換性のある移行（expand/contract）が問われやすいです。release branchは“例外的に必要な場面”を選べるかが肝です。

典型的な誤りは、長命なrelease運用でmainと差分が拡大する、バックフィルを本流に混在させてPRが通らない、スキーマ変更で下流を壊す、など。いずれも小さな差分・タグ分離・state活用・段階移行で回避できます。

• 基本はtrunk-based。releaseは監査・外部公開・凍結・大規模移行など限定条件で採用
• PR CIで state:modified と defer を併用し、差分+下流のみを検証
• 互換性を壊す変更はexpand/contractで段階的に進め、契約（contracts）を守る

contractsとテストの最小例

models:
  - name: fct_orders
    config:
      contract: true
    columns:
      - name: order_id
        data_type: int
        tests:
          - unique
          - not_null
      - name: customer_id
        data_type: int
        tests:
          - relationships:
              to: ref('dim_customers')
              field: customer_id

問題で確認

よくある質問