データ基盤のCI/CDは「データ変換コードの変更を安全・高速にデプロイする仕組み」です。dbtのモデル変更をPRでレビューし、自動テストを通過したものだけ本番に反映する。この一連のフローを構築することで、「リリースのたびにダッシュボードが壊れる」という問題を根本から解消できます。

なぜデータ基盤にCI/CDが必要か

ソフトウェア開発ではCI/CDが当たり前ですが、データ基盤では導入が遅れているケースが多くあります。「dbtのモデルを本番に直接デプロイ」「テストなしで変更をマージ」――これらは品質問題の温床です。

データ基盤でCI/CDが難しい理由は主に3つあります。①テスト用データの準備が必要、②DWH環境の分離コストがかかる、③スキーマ変更が下流に与える影響が広い。しかしdbt・GitHub Actionsの組み合わせにより、このハードルは大きく下がっています。

データ基盤CI/CDの全体像

データ基盤CI/CDパイプライン

[開発者]
  |  PR作成
  v
[CI: 品質ゲート]
  +-- SQLFluff: SQLスタイルチェック
  +-- dbt compile: 構文チェック
  +-- dbt test (変更モデルのみ): 品質テスト
  +-- コードレビュー
  |  全通過 → mainへマージ
  v
[CD: 本番デプロイ]
  +-- dbt run (本番DWH): 変換実行
  +-- dbt test (本番): 品質確認
  +-- ドキュメント更新: dbt docs generate
  |  完了
  v
[監視: 継続確認]
  +-- SLA監視 / アラート
フェーズ目的タイミング主なチェック項目
CI (継続的インテグレーション)PRマージ前の品質保証PR作成・更新時SQLlint / dbt compile / dbt test (変更分)
CD (継続的デリバリー)本番への安全な自動デプロイmainブランチへのマージ後dbt run / dbt test / ドキュメント更新 / 通知

CIの実装――PRマージ前の品質ゲート

CIの核心はdbt Slim CI――変更のあったモデルとその下流のみをテストする機能です。全モデルを毎回実行するよりも大幅にコスト・時間を削減できます。

# .github/workflows/dbt_ci.yml
name: dbt CI

on:
  pull_request:
    paths:
      - 'models/**'
      - 'tests/**'
      - 'macros/**'

jobs:
  dbt-ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install dbt
        run: pip install dbt-snowflake sqlfluff sqlfluff-templater-dbt
      - name: dbt deps
        run: dbt deps
      - name: SQLFluff lint
        run: sqlfluff lint models/ --dialect snowflake
      - name: dbt compile
        run: dbt compile --target ci
      # 変更されたモデルのみテスト (Slim CI)
      - name: dbt run - changed models
        run: dbt run --select state:modified+ --defer --state ./prod_artifacts --target ci
      - name: dbt test - changed models
        run: dbt test --select state:modified+ --defer --state ./prod_artifacts --target ci

SQLFluffによるスタイルチェック設定例です。チームのコーディングルールをコードとして管理します。

# .sqlfluff (プロジェクトルートに配置)

[sqlfluff]

templater = dbt dialect = snowflake max_line_length = 120

[sqlfluff:rules:layout.select_targets]

wildcard_policy = forbid

[sqlfluff:rules:aliasing.table]

aliasing = explicit

CDの実装――本番デプロイの自動化

mainブランチへのマージが承認されると、本番DWHへの自動デプロイが走ります。失敗した場合はSlackに通知し、ロールバック手順が起動します。

# .github/workflows/dbt_deploy.yml
name: dbt Deploy to Production

on:
  push:
    branches: [main]
    paths:
      - 'models/**'

jobs:
  dbt-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install dbt
        run: pip install dbt-snowflake
      - name: dbt deps
        run: dbt deps
      - name: dbt run (production)
        run: dbt run --target prod --full-refresh-on-schema-change
      - name: dbt test (production)
        run: dbt test --target prod
      - name: dbt docs generate
        run: dbt docs generate --target prod
      # テスト失敗時はSlack通知 (Slack webhook URLは Secrets で管理)

スキーマ変更のCI/CD

スキーマ変更は下流のダッシュボードやアプリケーションに影響します。変更の種別によって安全性が異なるため、対応方針を事前に定めておきます。詳細はスキーマ進化の記事も参照ください。

変更種別後方互換性CI対応CD対応リスク
カラム追加あり自動テストのみ自動デプロイ低
カラム名変更なし影響範囲確認必須手動承認後デプロイ高
カラム削除なし下流依存チェック段階的廃止 (Deprecation)高
データ型変更場合による型チェックテスト手動承認後デプロイ中〜高
テーブル追加あり自動テストのみ自動デプロイ低

ベストプラクティス

データ基盤CI/CDの成熟度を高める実践的なポイントです。

  • PR環境の分離: CIはdev/ciターゲット (専用スキーマ) を使い、本番DWHへのコストを最小化します
  • Slim CIの徹底: –select state:modified+ オプションで変更モデルのみを対象にし、実行コストを90%以上削減できます
  • テストカバレッジ指標化: dbt_meta_testingパッケージでカラム単位のテストカバレッジを計測し、PR時にレポートします
  • ロールバック戦略: dbt snapshot活用による変更前データの保全と、以前のartifactsを使った再デプロイ手順を文書化します
  • dbt Cloud Slim CI: dbt CloudはSlim CIをGUI設定のみで有効化でき、GitHub Actions不要です

まとめ――データ基盤CI/CDは「品質文化」の基盤

  • CI: PR時にSQLlint・dbt compile・dbt testを自動実行し、品質ゲートを設ける
  • CD: mainマージ後に本番デプロイを自動化し、ドキュメント更新も組み込む
  • Slim CI (state:modified+) でコストを最小化しながら品質を保証
  • スキーマ変更は種別に応じた対応方針を事前に決めておく
  • dbt Cloud利用ならCI機能が組み込まれており、GitHub Actions設定不要

次に読むべき記事: dbt入門 / dbt Core vs Cloud / データ品質テスト自動化

データ基盤のCI/CD設計・構築については、DE-STKにご相談ください。

よくある質問 (FAQ)

Q. データ基盤のCI/CDは通常のソフトウェア開発と何が違いますか?

データの存在が前提になる点が最大の違いです。テスト用データの準備・DWH環境の分離・クエリコストの管理が追加で必要になります。

Q. dbt CloudならCI/CDは不要ですか?

dbt CloudにはCI機能 (Slim CI) が組み込まれていますが、TerraformなどのIaC管理や周辺ツールのCI/CDは別途必要です。dbt Cloud + GitHub Actionsの併用が一般的です。

Q. CI/CDでのDWH費用を抑えるには?

dbtのSlim CI (変更されたモデルのみテスト)・小規模なウェアハウスの使用・テスト完了後の環境自動削除が有効です。Slim CI導入で実行コストを90%以上削減できるケースもあります。