根據前面提到的 dbt Core 架構， CI/CD 是必須的流程，也是 dbt Cloud 在 deploy 前可以設定的流程，那用 dbt Core 要做什麼事及怎麼做呢?

我們可以從下面方向整理

1. dbt run 是否正確

根據大部分 CI 的定義，要做到兩件事

建置: 確保提交的程式碼可以執行
**自動化測試:**確保功能正常與品質

在 dbt 的框架下要通過以上 CI 項目就是跑過一次沒有出現錯誤的 dbt run

2. 測試 db 環境

根據 dbt Cloud 的 CI 介紹文中的一段

dbt Labs recommends that you create your CI job in a dedicated dbt Cloud deployment environment that's connected to a staging database

所以我們應該把 CI 流程的 db 與正式 db 隔開，以 bigquery 為例，可以在正式 {dataset} 加上後綴 {dataset}_staging。

3. 資料品質檢查
   由於 dbt 是更新你資料庫的資料，因此就算 dbt run 通過，你更新的 table 還是有可能出錯，例如: join 錯表，key 值有 null; 或 key 值有重複值。這些資料品質的檢查也可以列為 CI 項目，這時就需要 dbt test 登場

總和上述3點，我們大概知道要做什麼 CI 項目，接下來分享 Migo 的 data team 團隊怎麼做 dbt CI

以 jenkins 寫法為例，我們在 branch PR 的階段可以執行以下語法當作 CI 項目

sh "dbt clean" 
sh "dbt deps " 
sh "dbt compile "
sh "dbt build --select ${files} --vars 'env: staging' --exclude 'source:*'" 

• dbt clean: 清除過去跑過的 dbt log 檔
• dbt deps: 安裝相關套件
• dbt compile: 編譯 models 為 sql 檔，確認格式是否正確
• dbt build --select ${files} --vars 'env: staging' --exclude 'source:*'
  • dbt build 同時執行 dbt test+dbt run，確認 models 正常跑且設定的 dbt test 資料品質檢查項目也通過
  • —select 為篩選只跑這次 branch 更動的檔案，跑全部檔案花時間又花資源
  • --vars 'env: staging' 設定 env 為 staging, 讓測試及正式環境隔開
  • --exclude 'source:*'" test 排除 source 檔因為資料一天更新一次，我們 source test 有檢查資料是否更新，若在每天資料更新時間前跑 CI 會出現錯誤

下一篇會介紹 CD 的項目及完整 jenkins