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

2025.09.18

 はじめにdbt Cloud では dbt プロジェクト用の Git リポジトリがまだない場合に、 dbt 側にリポジトリのホスティングと管理を任せることが可能です。こちらを使ってmain から派生した別のブランチ起点の開発を試してみました。
 注意点!前提として、本番環境ではマネージドリポジトリの使用は推奨されていません。マネージドリポジトリでは、プルリクエストなどの一部 Git 機能が制限されます。

この前提を理解した上で、一時的な検証目的でマネージドリポジトリを使用し、タイトルのような開発を行う手順を試してみます。
 前提条件以下の環境で検証しています。
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」を指定します。
 プロジェクトの初期化プロジェクトを初期化後、各種ファイルを以下のように設定しました。

					
			# 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.

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

※簡単にAccountadminとしている点はご注意ください。
本番環境
Deployment credentials 内の Schema は「prd」と指定（デフォルトでは指定のデータベースの prd スキーマにモデルがビルドされる）

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

環境作成後、環境変数を追加します。
 ジョブを作成以下の通り各環境へのデプロイジョブを作成します。マネージドリポジトリを使用する場合、CI ジョブやマージジョブは使えないため、通常のデプロイジョブとして作成します。
ここではいずれもdbt buildを実行するとしています。
本番環境へのデプロイジョブ
STG 環境へのデプロイジョブ
 ブランチを作成ここから前提条件に沿ったブランチを作成します。Studio（開発環境）でのデフォルトブランチは main となっているので、下図よりブランチを作成します。
stgブランチとして作成します。
 カスタムブランチを変更今回の設定ではstgブランチからfeature/xxブランチを派生させ、開発を行います。dbt Cloud では指定の保護対象のブランチ（デフォルトは main）からしかブランチを作成できないため、カスタムブランチをstgブランチに変更します。
「Orchestration > Environments 」から開発環境（Development）を選択し、設定変更より下図のように「Default to a custom branch」にチェックを入れstgブランチを指定します。
この状態で Studio に入るとstgブランチが保護対象のブランチとなります。
続けて、STG 環境についてもカスタムブランチをstgブランチに変更します。STG 環境へのデプロイジョブは、stgブランチの内容をもとに行いたいため、この設定とすることで、ジョブ実行時にstgブランチ内容がクローンされ実行されます。
 stg ブランチで開発を行うStudio（開発環境）で各種開発を行います。stgブランチから開発用のブランチを作成します。
ここでは各種開発を行ったとして、開発環境でdbt runを実行します。実行後、開発環境アカウントの指定のデータベースに開発者用のスキーマが作成され、各種モデルが作成されます。
変更をコミットします。
変更をマージします。stgブランチがカスタムブランチとして指定されているので、マージ先はstgブランチとなります。
 STG 環境へのデプロイジョブを実行stgブランチに変更が反映されたので、ジョブを実行します。マネージドリポジトリではマージジョブ等は使用できないので、デプロイジョブとして手動実行しました。
実行履歴を見ると、stgブランチを使用していることがわかります。
実行後、STG 環境アカウントの指定のデータベースに Deployment credentials で指定した名称（stg）でスキーマが作成され、各種モデルが作成されます。
 main ブランチに変更をマージカスタムブランチとしてstgを指定した場合、dbt Cloud の UI 上でのマージ先はstgブランチに固定されます。そのため、feature/xxブランチからの変更を最終的にmainブランチに統合するには、カスタムブランチの設定をデフォルトブランチ（mainブランチ）に都度切り替える必要があります。
実際はこのような運用は推奨できないと思いますが、ここではマネージドリポジトリを使用する設定での検証のため、再度開発環境のカスタムブランチを変更します。（下図のチェックを外す）
この状態から Studio を開き、stgブランチにいる状態であれば、mainにマージできます。
 本番環境へのデプロイジョブを実行この状態で本番環境向けのジョブを実行します。本番環境では特にカスタムブランチの設定をしていないので、mainブランチがクローンされます。
ジョブ完了後、本番環境アカウントを確認すると指定のデータベースに Deployment credentials で指定した名称（prd）でスキーマが作成され、各種モデルが作成されます。
 さいごにdbt Cloud のマネージドリポジトリを使った main から派生した別のブランチ起点の開発を試してみました。

カスタムブランチを使えば、このような開発も可能となります。ただし、現時点では、本番環境はもちろん検証時もマネージドリポジトリを使用するこのようなブランチ構成での開発は推奨されないと思いました。

こちらの内容が何かの参考になれば幸いです。