GitHub 的數據庫 CI/CD 優秀實踐
數據庫更改是應用程序開發過程中一個棘手的部分：它通常涉及來自不同環境的多個數據庫和跨團隊協作，此外，數據庫是一觸即發的。它讓我們思考：我們可以像對待應用程序代碼一樣對待數據庫嗎？
DORA（DevOps Research & Assessment）指出，將數據庫工作整合到軟件交付過程中，對持續交付有積極的貢獻。是時候讓數據庫成為 CI/CD 周期的一部分了。
但它是如何工作的？
數據庫 CI/CD 的關鍵要素
要回答“如何”，我們首先需要梳理一下典型的數據庫變更工作流程。在 SQL 語句可以安全地應用于數據庫之前，有兩個關鍵步驟：review & change。
1. SQL 審查
此步驟是為了確保更改：
- 準確實現業務邏輯；
- 遵循數據庫設計最佳實踐；
在這里，開發人員通常負責前者的任務，而 DBA 則負責后者。DevOps 理念旨在通過集成 Ops 和 Devs 來解決這個問題。現實情況是，當組織中存在 DBA 時，很難將兩個團隊直接合并。一種可能的解決方案是保留 DBA 的任務，同時讓開發團隊能夠預審 SQL。這種左移方法可以顯著減少發布延遲的機會。此外，如果組織中沒有 DBA，那么賦予開發團隊以確保 SQL 不會對數據庫造成嚴重破壞的能力就更加重要。
2、SQL變更執行
此步驟是為了確保：
- 語句正確執行。我們不希望出現錯誤的數據庫連接、權限不足、對象名稱沖突或基本語法錯誤。
- 所有計劃的語句都被執行。當要執行的腳本很多或者有多個目標數據庫要批量執行時，可能會出現遺漏。
- 變更執行過程不應影響業務。硬件資源耗盡和長時間鎖定表對公司來說并不愉快。
為了避免與變更相關的錯誤，減少手動方面也很重要：自動化的事情越多，發生錯誤的機會就越少。預配置管道以自動將 SQL 應用于數據庫？聽起來不錯。為避免對常規業務運營產生負面影響，應采用各種零停機更改技術，尤其是對于具有大型數據集的數據庫。
因此，實施數據庫 CI/CD 的關鍵要素應該使開發團隊能夠執行 SQL 審查并簡化 SQL 更改推出。
使用 VCS 集成進行 SQL 審查和變更部署
讓我們首先探討如何讓開發團隊自己執行 SQL 審查。
很少有開發人員是審查 SQL 語句“架構正確性”的專家，即使對于高級 DBA，手動檢查也可能非常低效且容易出錯。幸運的是，業界通過集成不同的 SQL 檢查規范創建了各種自動審查工具。
然而，這些工具有一個共同的問題——它們都是為 DBA 設計的。一方面，這些工具往往需要更高的數據庫操作權限，因此不適合開發人員直接使用。另一方面，開發人員擁有自己的 IDE，而單獨的外部仲裁器是他們最不需要的東西。想象一下，當您必須在多個工具之間復制和粘貼代碼時會有多糟糕。
那么開發人員友好的 SQL 審查工具應該是什么樣的呢？
我們通常在版本控制系統 (VCS) 上執行傳統的代碼審查流程，SQL 也應如此。因此，應該將 SQL 審查工具集成到代碼審查工作流程中。啟用后，當您在 GitHub 上提交 PR 時，將觸發GitHub Marketplace 上可用的 SQL Review Action 。
讓我們看看如何實現簡化的 SQL 更改推出。
獨立的 SQL 部署工具并不少見。這些工具通常手動上傳 SQL 腳本，通過審批流程繼續部署，然后在部署完成后提供反饋。該模型準確地描述了開發人員和 DBA 如何獨立工作，而分散的流程是延遲發布的最常見原因之一。畢竟，當您在多個系統之間不斷手動移動 SQL 腳本時，誰能保證永遠不會出錯？
我們需要一個更高效和自動化的發布流程。讓我們回顧一下應用程序代碼的經典 CI/CD 工作流程：提交更改 > 代碼審查 > 合并分支 > 自動構建 > 自動部署。既然我們已經在 GitHub Actions 上實現了 SQL 審查，為什么不能包括后續的推出流程呢？
嗯，是的，我們可以！
用于數據庫 CI/CD 的 SQL 更改推出工具應該能夠與 VCS 集成。一旦您的 SQL 腳本經過審查并合并到目標分支中，就會觸發發布過程，并且腳本會自動推送到 Bytebase。當然，DBA 可以在針對目標數據庫執行 SQL 之前執行另一次完整性檢查。
完整的數據庫 CI/CD 工作流程
在這里，我們展示了一個完整的數據庫 CI/CD 工作流程：
- 開發者創建一個包含 SQL 遷移腳本的 Merge Request / Pull Request；
- 自動觸發 SQL Review Action 來審查 SQL 并提供建議以協助代碼審查；
- 經過幾次可能的迭代后，開發團隊中的團隊領導或其他同事批準更改并將 SQL 腳本合并到一個分支中；
- 合并事件自動觸發 Bytebase 中的發布管道，并創建捕獲預期更改的發布票；
- （可選）DBA 或指定的審閱者可以通過 Bytebase 的內置 UI 審閱更改腳本；
- 批準的腳本會根據配置的上線階段逐步執行；
- 應用更改后，最新的數據庫模式會自動寫回代碼存儲庫。這樣一來，開發團隊始終擁有最新架構的副本。此外，他們可以根據最新模式的變化配置下游管道；
- 確認遷移并繼續進行相應的應用程序推出。
此工作流程非常適合現有的 CI/CD 流程，并且對開發人員來說很自然。敏銳的讀者可能已經發現所描述的步驟是具有里程碑意義的文章Evolutionary Database Design的實現。
