dbt CI/CD の全体像: プルリクから本番までの流れ

本稿は、dbt Cloud でも dbt Core + GitHub Actions でも通用する「安定した」運用設計をベースに、PR からマージ、本番反映までの判断ポイントを具体化します。

試験対策として問われやすいキーワード（Slim CI、state artifacts、defer、run/test/build、環境分離）を、実務の設定例と併せて最短で押さえます。

CI/CD の前提と全体像

dbt の CI/CD は「変更の影響範囲だけを素早く検証する CI」と「安全に本番へ昇格させる CD」を分けて設計します。基本は PR 作成で CI を自動起動し、state:modified と defer を用いて差分だけを検証。マージ後は本番ジョブがスケジュールまたはイベントで走り、安定したリソースに対して run/test を実行します。

データベース／レイクハウス側は環境・スキーマで隔離します。開発者やブランチごとの一時スキーマに CI の成果物を出力し、本番は固定スキーマ（カタログ）にのみ書き込み権限を与えます。

• 環境の三層化: 開発（dev）/ 検証（stg）/ 本番（prod）
• Slim CI: state:modified+ と defer で差分と依存を最小実行
• ジョブ分離: PR CI ジョブ、ステージング統合ジョブ、本番ジョブ
• アーティファクト管理: manifest.json・run_results.json を保存し CI の state に流用
• 権限・隔離: 各環境のロール/スキーマ/カタログを分離（Snowflake/Databricks いずれも有効）

PR から本番までの高レベルフロー

Dev (branch)
   |  open PR
   v
[CI Job] --- build(test) on temp schema
   |  status check green?
   v
merge to main
   |
   v
[CD Job (prod)] -- run/test on prod schema
   |
   v
Publish docs / exposures
   |
   v
Consumers (BI/ML)

selectors.yml の例（差分を優先的に実行）

selectors:
  - name: pr_changed
    definition:
      union:
        - method: state
          value: modified
          children: true
        - method: tag
          value: always_ci

プルリク作成〜CI 実行（Slim CI の型）

PR が作られると CI が起動し、当該ブランチの変更モデルとその下流（+）のみを build します。参照先は defer で既存の安定版（通常は prod のアーティファクト）に差し替え、未変更部分を再計算しないのがポイントです。

CI では本番と同一のアダプタ設定（Snowflake/Databricks など）を使いながらも、出力先はブランチ専用の一時スキーマに切り替えます。成功時はステータスチェックを Git プラットフォームへ返し、レビューアはテスト通過と結果要約を確認します。

• state:modified+ で変更点と依存を最小限に実行
• defer で未変更の上流参照を本番アーティファクトに委譲
• PR 単位の一時スキーマ（命名規則にブランチ名/短縮ハッシュ）
• dbt test の重大失敗をステータスチェックに反映（Quality Gate）

CI 内部フロー（概念）

N/A

GitHub Actions での Slim CI 実装例

name: dbt CI (PR)
on:
  pull_request:
    branches: [ main ]
jobs:
  slim-ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'
      - name: Install dbt-core + adapter
        run: |
          pip install dbt-core dbt-snowflake  # or dbt-databricks
      - name: Restore prod artifacts (state)
        uses: actions/download-artifact@v4
        with:
          name: prod_artifacts
          path: ./.state
      - name: dbt deps
        run: dbt deps
      - name: dbt build (Slim CI)
        env:
          DBT_USER: ${{ secrets.SNOWFLAKE_USER }}
          DBT_PASSWORD: ${{ secrets.SNOWFLAKE_PASSWORD }}
          DBT_ACCOUNT: ${{ secrets.SNOWFLAKE_ACCOUNT }}
          DBT_SCHEMA: pr_${{ github.event.number }}
        run: |
          dbt build --select state:modified+ \
                    --defer --state ./.state \
                    --target ci
      - name: Upload CI artifacts
        uses: actions/upload-artifact@v4
        with:
          name: ci_artifacts
          path: target/*.json

マージ後の CD と本番反映

main にマージされると本番系ジョブが起動します。CI では defer により既存本番を参照しましたが、本番ジョブでは実際の prod 用接続・スキーマへ出力します。スケジュール駆動とイベント駆動の併用も現実的です（高頻度モデルはイベント、重い集計はスケジュール）。

本番では run と test を明確に分けるか、build 一発でまとめるかはチームの方針次第です。重要なのは、失敗時に部分成功を残したままにしないこと、アーティファクトを確実に保存して次回の state に使うことです。

• 本番はフルではなく「変更中心 + 依存」に留める設計も有効
• docs 生成と exposures の更新をジョブ末尾で自動化
• アーティファクト（manifest, run_results）を長期保存し次回 state に利用
• 権限付与（grants）は専用マクロ/後工程で安定適用

CD のシンプルな実行順序

N/A

本番ジョブのコマンド例（順序の分離）

dbt deps
# 必要に応じて seed / snapshot
# dbt seed --full-refresh
# dbt snapshot
# 変更中心の実行（十分に安定運用ならフル実行も可）
dbt run --select state:modified+
dbt test --select state:modified+
# アーティファクト保存（ワークフロー側で target/*.json を保管）

データベース側の隔離戦略（スキーマ/カタログ設計）

CI の安全性はスキーマ（またはカタログ）隔離で決まります。PR ごとに一時スキーマを作り、CI 終了後はクリーンアップします。Snowflake なら ROLE/WAREHOUSE/SCHEMA を分け、Databricks Unity Catalog なら catalog.schema を明確に分離します。

スキーマ名はブランチや PR 番号をエンコードして衝突と不正文字を避けます。dbt の generate_schema_name マクロを上書きすれば、安全な命名をチーム共通ルールにできます。

• Snowflake: 最小権限の ROLE に一時スキーマ作成・書込のみ付与
• Databricks: 開発用 catalog を分離し、prod catalog への書込を禁止
• クリーンアップ: 古い PR スキーマは TTL で drop（定期ジョブ）
• 命名: 例）ci_pr123_userx や ci_b_<short_sha> のように簡潔に

隔離イメージ（概念）

N/A

schema 命名マクロ例（ブランチ名を安全化）

{% macro generate_schema_name(custom_schema_name, node) -%}
  {%- set raw = env_var('GIT_BRANCH', 'pr') | lower -%}
  {%- set safe = re.sub('[^a-z0-9_]', '_', raw) -%}
  {%- set prefix = 'ci_' ~ safe[0:20] -%}
  {{ return(prefix) }}
{%- endmacro %}

テスト、品質ゲート、アーティファクト管理

品質ゲートは dbt test の重大失敗で PR を止める仕組みです。unique/not_null/accepted_values などの一般的テストは CI でも有効で、重い検査（行数大、統計的比較など）はステージングで実施するとバランスが取れます。

アーティファクト（manifest.json/run_results.json）は必ず保存し、次回 CI の state として参照します。これにより Slim CI が成立し、未変更領域の再計算を避けられます。ドキュメント（catalog.json）や exposures も同時に更新し、下流利用者への可視性を担保します。

• 軽量テストを CI、重い/回帰系を stg/prod に配分
• run_results.json をステータス要約と合わせて保管
• manifest.json を CI の --state に利用（長期保存推奨）
• ブランチ保護で CI 成功を必須化（Required status checks）

アーティファクトの流れ（概念）

N/A

schema.yml のテスト例（抜粋）

version: 2
models:
  - name: fct_orders
    tests:
      - unique:
          column_name: order_id
      - not_null:
          column_name: order_id
      - relationships:
          to: ref('dim_customer')
          field: customer_id

失敗時のロールバックと運用の要点

本番失敗時は、まず直近のコミットをリバートして再実行します。テーブル更新の失敗で中途半端な状態が懸念される場合は、ブルー/グリーン（next スキーマに構築→ビュー切替）で可視層を安全に入れ替える設計が有効です。

権限と破壊的変更を分離し、drop や full-refresh はメンテナンスウィンドウに限定。スナップショットは本番のみで運用し、CI では通常スキップします。

• ロールバック基本: Git の revert + 本番ジョブ再実行
• 可視層の切替: create or replace view で current → next を即時反映
• grants 専用マクロで安定適用（データ再生成と分離）
• 破壊的変更の計画適用（契約: contracts で前方互換を担保）

ブルー/グリーン切替（概念）

N/A

ビュー切替の簡易スクリプト例（SQL）

-- next スキーマで build 済みを想定
-- 可視スキーマのビューを next へ切替
create or replace view prod.visible.fct_orders as
select * from prod_next.fct_orders;

問題で確認

よくある質問