CI/CD 是一個穩健的資料系統中必備的要素。能確保系統穩定性與高效率的開發，雖然需要額外的心力來維護，但開發起來絕對比過去我們時常直接把東西丟上 production 看看正不正常好多了，那種像是丟骰子一樣的開發流程，對心理健康有害。

透過轉移至 dbt 的過程中，我們也趁機在其中加上了 CI/CD 的架構，在 CI 階段，我們在測試環境中運行該 PR 修正的項目，確保其調整的模型都能夠正常運行；而在 CD 階段中則將修正的模型在生產環境中更新，確保 PR 在 Merge 後，資料表就是最新的狀態。

回想起以前每次 Merge 完之後又要重新部署，又要檢查有沒有問題，要趕緊在下次有需求時修復等等，讓我們的 Scrum 跑起來也更加穩健，不會天天被隕石插單。

在 CI/CD 的過程中，我們主要要確認的就是 dbt compile, build 是否能成功運行，為此我們需要掌握該 PR 修正了哪些模型。

dbt 有一個很不錯的功能，是 state。（文件）

dbt test --select "state:new" --state path/to/artifacts      # run all tests on new models + and new tests on old models
dbt run --select "state:modified" --state path/to/artifacts  # run all models that have been modified
dbt ls --select "state:modified" --state path/to/artifacts   # list all modified nodes (not just models)

透過 state:modified 的參數、搭配 compile 後的 json file，我們就可以比較出原先的資料模型與現在 PR 的資料模型的差異，進而檢查有差異的模型是否能正常運行。

話雖如此，我們目前沒有使用 dbt 這個看起來十分好用的功能。

最主要的原因是，我在剛開始部署 CI/CD 流程的時候呢，沒有注意到他有這個方法。（蛤？！）

後來看到的時候說實話其實是有點懊悔的，花了幾天才做完的，結果這邊有現成的工具。不過後來研究了一下，也是需要在 git 中做切換，針對不同的狀態做 parsing，才有辦法知曉他們之間的差異的，知道要花一些時間，讓我覺得心情平衡一些。

我當時使用的方法是，直接用 git diff 去比較 PR 與 main branch 之間有變化的 SQL file，把這些 file name 作為參數傳進 dbt 的指令當中使用。

不過他就不像 dbt state 中，可以辨別修正的內容範圍，dbt state 可以辨認是針對模型內容、資料夾名稱、macro 改動等等，可以針對你在意的改動去做測試即可。而用 git diff 的話，只要檔案有任何調整，包含格式化，都會被抓出來，但幸好目前影響不大。

不過他也是有它的好處的，這個好處容我賣個關子，後續幾篇再提，主要是跟 dbt 下游的其他工具的協作有關。