developersIO
dbt Cloud のマネージドリポジトリで main から派生した別のブランチ起点の開発を試してみた

dbt Cloud のマネージドリポジトリで main から派生した別のブランチ起点の開発を試してみた

モダンデータスタック(MDS)
dbt Cloud
FacebookHatena blogX
2025.09.18

はじめに

dbt Cloud では dbt プロジェクト用の Git リポジトリがまだない場合に、 dbt 側にリポジトリのホスティングと管理を任せることが可能です。こちらを使ってmain から派生した別のブランチ起点の開発を試してみました。

注意点

前提条件

以下の環境で検証しています。

  • DWH：Snowflake
  • 環境：Snowflake アカウントレベルで分離
    • PROD：本番環境
    • STG：統合テスト環境。複数の開発者が作成したモデルをマージし、品質保証を行う環境
    • DEV：各ユーザーが新しいデータを開発する、個人の開発環境
  • データベース構成
    • 各環境（アカウント）で dbt による開発結果を出力する単一のデータベースを用意
      • 例：<env>_db
  • ブランチ戦略
    • mainブランチと同期されたstgブランチを作成
    • stgブランチからfeature/xxブランチを派生させ、開発を行う
    • 開発完了後、feature/xxからstgへブランチにマージする
    • STG 環境でテストが完了したら、stgブランチの変更をmainブランチにマージする
  • ジョブ構成
    • 本番環境へのデプロイジョブ
      • mainブランチの変更を本番環境へ反映する
    • STG 環境へのデプロイジョブ
      • stgブランチの変更を STG 環境へ反映する
      • カスタムブランチとしてstgを指定する

考慮事項

  • ブランチの作成
    • dbt Cloud のマネージドリポジトリの既定の設定ではデフォルトブランチ（通常はmain）からしか新しいブランチを派生させることができません。つまり、派生させたブランチからさらにブランチを作成することはできません
    • カスタムブランチを使用するとmain以外の任意のブランチを「デフォルトブランチ」として扱うことができ、指定したブランチからブランチを派生させることが可能になります
    • 今回の設定では、main以外のstgブランチからfeature/xxブランチを派生させて開発を行いたいため、stgブランチをカスタムブランチとして設定します
  • mainブランチへのマージ
    • dbt Cloud のマネージドリポジトリでは、マージの動作に制約があります。例えば、カスタムブランチとしてstgを指定した場合、dbt Cloud の UI 上でのマージ先はstgブランチに固定されます。そのため、feature/xxブランチからの変更を最終的にmainブランチに統合するには、マネージドリポジトリのUIだけでは完結しません
    • マネージドリポジトリを使用し UI 上で、stgからmainへの統合を行いたい場合は、カスタムブランチの設定をデフォルトブランチ（mainブランチ）に都度切り替える必要があり、運用の手間や誤操作、複数人での開発時は問題となる可能性が高いです

試してみる

事前準備

Snowflake 側で3つのアカウントを用意し、各環境で環境を表す変数名を変更し、以下を実行しました。

これにより、dbt Cloud の出力先となるデータベースとレイヤーごとのスキーマが作成されます。サンプルデータは Quickstart で提供される jaffle_shop のデータを使用しました。

--変数を定義
--環境名: prd, stg, dev 
SET env_name = '<env>';
--データベースを作成
SET db_name = concat($env_name,'_db');
create database if not exists identifier($db_name);

--スキーマを作成
use database identifier($db_name);
--raw
create schema raw;

--ウェアハウスを作成
create warehouse if not exists transforming;

--データロード
use schema raw;
--customers
create table customers 
( id integer,
  first_name varchar,
  last_name varchar
);

copy into customers (id, first_name, last_name)
from 's3://dbt-tutorial-public/jaffle_shop_customers.csv'
file_format = (
    type = 'CSV'
    field_delimiter = ','
    skip_header = 1
    ); 

--orders
create table orders
( id integer,
  user_id integer,
  order_date date,
  status varchar,
  _etl_loaded_at timestamp default current_timestamp
);

copy into orders (id, user_id, order_date, status)
from 's3://dbt-tutorial-public/jaffle_shop_orders.csv'
file_format = (
    type = 'CSV'
    field_delimiter = ','
    skip_header = 1
    );

--データを確認
select * from customers;
select * from orders;

コネクションを作成

dbt Cloud ではコネクションで DWH への接続を管理できます。ここでは環境別に3つのアカウントを用意したので、環境ごとにコネクションを作成しておきました。

プロジェクトを作成

検証用のプロジェクトを作成します。リポジトリは「Managed」を指定します。

image

プロジェクトの初期化

プロジェクトを初期化後、各種ファイルを以下のように設定しました。

# models セクションのみ抜粋
models:
  jaffle_shop:
    +materialized: view

sources.yml はデータベースに環境変数を使用することとしました。

version: 2

sources:
    - name: jaffle_shop
      description: This is a replica of the Postgres database used by our app
      database: "{{ env_var('DBT_DATABASE') }}"
      schema: raw
      tables:
          - name: customers
            description: One record per customer.
          - name: orders
            description: One record per order. Includes cancelled and deleted orders.

あわせてプロジェクトで環境変数を定義します。

image 1

この上で、プロジェクトとあわせて作成される開発環境の設定を以下のように変更します。これにより、dbt Cloud におけるモデルのデフォルト出力先データベースと、今回はソースでもこの変数を指定したので、ソースで参照先となるデータベースを環境変数から取得できます。

image 2

環境を作成

プロジェクト作成時は、開発環境が作成されるので、本番環境・STG環境を作成します。
※簡単にAccountadminとしている点はご注意ください。

  • 本番環境
    • Deployment credentials 内の Schema は「prd」と指定（デフォルトでは指定のデータベースの prd スキーマにモデルがビルドされる）

image 3

  • STG環境
    • Deployment credentials 内の Schema は「stg」と指定（デフォルトでは指定のデータベースの stg スキーマにモデルがビルドされる）

image 4

環境作成後、環境変数を追加します。

image 5

ジョブを作成

以下の通り各環境へのデプロイジョブを作成します。マネージドリポジトリを使用する場合、CI ジョブやマージジョブは使えないため、通常のデプロイジョブとして作成します。

ここではいずれもdbt buildを実行するとしています。

  • 本番環境へのデプロイジョブ
  • STG 環境へのデプロイジョブ

image 6

ブランチを作成

ここから前提条件に沿ったブランチを作成します。Studio（開発環境）でのデフォルトブランチは main となっているので、下図よりブランチを作成します。

image 7

stgブランチとして作成します。

image 8

カスタムブランチを変更

今回の設定ではstgブランチからfeature/xxブランチを派生させ、開発を行います。dbt Cloud では指定の保護対象のブランチ（デフォルトは main）からしかブランチを作成できないため、カスタムブランチをstgブランチに変更します。

「Orchestration > Environments 」から開発環境（Development）を選択し、設定変更より下図のように「Default to a custom branch」にチェックを入れstgブランチを指定します。

image 9

この状態で Studio に入るとstgブランチが保護対象のブランチとなります。

image 10

続けて、STG 環境についてもカスタムブランチをstgブランチに変更します。STG 環境へのデプロイジョブは、stgブランチの内容をもとに行いたいため、この設定とすることで、ジョブ実行時にstgブランチ内容がクローンされ実行されます。

image 11

stg ブランチで開発を行う

Studio（開発環境）で各種開発を行います。stgブランチから開発用のブランチを作成します。

image 12

ここでは各種開発を行ったとして、開発環境でdbt runを実行します。実行後、開発環境アカウントの指定のデータベースに開発者用のスキーマが作成され、各種モデルが作成されます。

image 13

変更をコミットします。

image 14

変更をマージします。stgブランチがカスタムブランチとして指定されているので、マージ先はstgブランチとなります。

image 15

STG 環境へのデプロイジョブを実行

stgブランチに変更が反映されたので、ジョブを実行します。マネージドリポジトリではマージジョブ等は使用できないので、デプロイジョブとして手動実行しました。

実行履歴を見ると、stgブランチを使用していることがわかります。

image 16

実行後、STG 環境アカウントの指定のデータベースに Deployment credentials で指定した名称（stg）でスキーマが作成され、各種モデルが作成されます。

image 17

main ブランチに変更をマージ

カスタムブランチとしてstgを指定した場合、dbt Cloud の UI 上でのマージ先はstgブランチに固定されます。そのため、feature/xxブランチからの変更を最終的にmainブランチに統合するには、カスタムブランチの設定をデフォルトブランチ（mainブランチ）に都度切り替える必要があります。

実際はこのような運用は推奨できないと思いますが、ここではマネージドリポジトリを使用する設定での検証のため、再度開発環境のカスタムブランチを変更します。（下図のチェックを外す）

image 18

この状態から Studio を開き、stgブランチにいる状態であれば、mainにマージできます。

image 19

本番環境へのデプロイジョブを実行

この状態で本番環境向けのジョブを実行します。本番環境では特にカスタムブランチの設定をしていないので、mainブランチがクローンされます。

image 20

ジョブ完了後、本番環境アカウントを確認すると指定のデータベースに Deployment credentials で指定した名称（prd）でスキーマが作成され、各種モデルが作成されます。

image 21

さいごに

dbt Cloud のマネージドリポジトリを使った main から派生した別のブランチ起点の開発を試してみました。
カスタムブランチを使えば、このような開発も可能となります。ただし、現時点では、本番環境はもちろん検証時もマネージドリポジトリを使用するこのようなブランチ構成での開発は推奨されないと思いました。
こちらの内容が何かの参考になれば幸いです。

この記事をシェアする

FacebookHatena blogX

関連記事

dbt Cloud のマネージドリポジトリから GitLab への移行を試してみる
安原朋紀
2025.10.17
dbt CloudのジョブをAPIを介して実行してみた
かわばた
2025.10.15
dbt Coalesce 2025で発表された新情報まとめ
さがら
2025.10.15
[小ネタ]dbtのgrantsとSnowflakeのCOPY GRANTS・FUTURE GRANTSの関係を検証してみた
かわばた
2025.10.10