在我們的 CI/CD 流程中，有一個步驟是要先對 models 進行 dry-run，為何要進行 dry-run？以及要如何做？這篇將會一一介紹

為何需要 dry-run

在 CI/CD 流程當中，有一階段是執行所有異動 models 及其下游，但假設我們調整後的程式碼導致執行下游出錯（例如修改欄位名稱，但下游沒有跟著改），會導致前面執行了很多 models 但是在中間出錯，那前面執行所消耗的運算資源就浪費了。

因此在執行前會希望檢查改動後的 SQL 程式碼是不是可被執行的，那要如何確認是否可被執行？我們可以把 SQL 程式碼打在 BigQuery 上，如果有指令錯誤或是欄位名錯誤，介面上就會跳出錯誤警示，也可以透過 API 來執行，並且設定為 dry-run，如果有錯誤就會回傳，且不會實際去查詢，避免浪費資源。

dbt 本身並沒有 dry-run 功能（如果有歡迎大家在下面分享），我們團隊是使用 dbt-dry-run 一個第三方開發的套件來達到 dbt dry-run 功能。

dbt-dry-run

dbt-dry-run 這個套件是運用我們在 dbt compile 後的 SQL 程式碼，透過 python BigQuery API 來執行 dry-run，來達到檢查程式碼可否執行。如果想瞭解背後是如何運作的，可直接參考其 Github。

以下來介紹如何使用 dbt-dry-run：

1. 編譯 dbt models：在 dbt models 中可能會用很多 macro 來撰寫程式碼（像是常見的 ref, source），因此需要透過 dbt compile 指令將 SQL 程式碼編譯成能讓 BigQuery 執行的程式碼，如果在執行 dbt-dry-run 前沒有編譯，會跳出錯誤。
2. 執行 dbt-dry-run：dbt-dry-run 指令很間單，只要在 command line 打 dbt-dry-run 就可 dry-run 所有 models。但我們公司有許多客戶，每次 PR 也只會修改一個客戶，如果每次都 dry-run 所有 models 會花上不少時間，因此我們團隊將整個專案 fork 下來，並修改其中的程式碼加上 tags 的 flag，這讓我們能選取特定 tag models 執行 dry-run
3. 查看結果：dbt-dry-run 如果成功就會顯示成功訊息，失敗則會顯示哪些 models 失敗，如果上游的 models 已經失敗，下游就不會執行 dry-run。

以上介紹為何需要 dry-run，以及如何使用 dbt-dry-run 來進行 dry-run，下一篇將會介紹 CI/CD 中執行異動 models 的階段。

參考

• dbt-dry-run Github