
dbt CloudでCI/CDの設定を試してみた
かわばたです。
今回は、dbt CloudでCI/CDの設定の流れを紹介します。
本記事で行うこと
- CI/CDの設定
検証環境
- dbt Cloudのアカウント
- Snowflakeのアカウント
※dbt・SnowflakeともにEnterprise版を使用しています。
CI/CDとは
CI と CD をそれぞれ簡単に説明すると、継続的インテグレーション (CI) とは、コード変更を共有ソースコードリポジトリに自動的かつ頻繁に取り込む手法のことです。継続的デリバリーまたはデプロイメント (CD) は 2 つの部分からなるプロセスで、コード変更の統合、テスト、デリバリーを指します。継続的デリバリーは、本番環境への自動デプロイは行わずその手前までを守備範囲としますが、継続的デプロイメントは、更新内容を本番環境に自動的にリリースします。継続的デリバリーと継続的デプロイメントのどちらを選択するかは、リスク許容度と、開発チームと運用チームの具体的なニーズによって異なります。
システム開発におけるCI/CDは上記の考え方ですが、dbtにおけるCIの主な目的は、本番環境にマージする前にコードの変更をテストし、エラーを早期に発見することです。主なステップは以下の通りです。
1.プルリクエストの作成: 開発者が新しい機能の追加やバグ修正を行い、プルリクエストを作成します。
2. CIジョブのトリガー: プルリクエストが作成されると、CIジョブが自動的にトリガーされます。
3.一時的なスキーマの作成: CIジョブは、本番環境とは別の一時的なスキーマに、変更されたモデルとその下流にあるモデルを構築します。
4. テストの実行: dbt buildやdbt testコマンドを実行し、データの品質やモデルの参照関係に問題がないかを確認します。
5. 結果のフィードバック: テスト結果はプルリクエストにフィードバックされ、問題がなければマージが承認されます。
dbtにおけるCDは、CIでテストされたコードを自動的に本番環境にデプロイ(リリース)するプロセスです。これにより、手動でのデプロイ作業によるミスを防ぎ、迅速かつ確実に変更を本番環境に反映させることができます。
CIの設定
準備編
CIの設定の前に、テスト用のパイプラインを構築していきます。
詳細は割愛しますが、下記のブログの「dbtで行うこと」を実行しています。
※ただし、リポジトリの設定でdbtのリポジトリを使用していますが、今回はGitHubを使用しています。
【dbtとGitHubリポジトリの接続】
CI設定編
さきほど作成したテスト用のパイプラインにCIを設定していきます。
【公式ドキュメント】
- [Orchestration]から[job]を選択し、[Create job]から[Continuous integration job]を押下します。
-
下記画面に遷移するので、任意の[Job name]を変更し、保存します。
-
カラムを追加しpull requestします。※準備編で作成したテスト用パイプラインと差分を作成するため。
-
すると下記画面のように、さきほど作成したCIジョブが自動実行されます。
-
testが問題なく通ると下記のように新しいスキーマが生成され、CIジョブが反映されます。
Snowflake側も想定通りに値が反映されていました。
CDの設定
CDジョブを作成しpull requestがmainブランチにマージされたタイミングで、変更された内容を実行するようにします。
- [Orchestration]から[job]を選択し、[Create job]から[Merge job]を押下します。
- 下記画面に遷移するので、任意の[Job name]を変更し、保存します。
-
GitHubでMergeを行うと作成した[Merge job]が実行されます。
-
Snowflake側で確認します。
無事に本番環境である[PROD_SCHEMA]に反映することが出来ました。
また、CIジョブで作成された[DBT_CLOUD_PR_916925_6]スキーマですが、削除されていたため、デフォルトの[Merge job]設定では削除される仕様のようです。
最後に
いかがでしたでしょうか。
dbt CloudにおけるCI/CDの設定を試すことができ、全体の流れが掴めました。
今回は行いませんでしたが、新機能で「Advanced CI」もありますので是非ご確認ください。
この記事が参考になれば幸いです。