數(shù)據(jù)庫更改是應(yīng)用程序開發(fā)過程中一個棘手的部分：它通常涉及來自不同環(huán)境的多個數(shù)據(jù)庫和跨團隊協(xié)作，此外，數(shù)據(jù)庫是一觸即發(fā)的。它讓我們思考：我們可以像對待應(yīng)用程序代碼一樣對待數(shù)據(jù)庫嗎？

DORA（DevOps Research & Assessment）指出，將數(shù)據(jù)庫工作整合到軟件交付過程中，對持續(xù)交付有積極的貢獻。是時候讓數(shù)據(jù)庫成為 CI/CD 周期的一部分了。

但它是如何工作的？

數(shù)據(jù)庫 CI/CD 的關(guān)鍵要素

要回答“如何”，我們首先需要梳理一下典型的數(shù)據(jù)庫變更工作流程。在 SQL 語句可以安全地應(yīng)用于數(shù)據(jù)庫之前，有兩個關(guān)鍵步驟：review & change。

1. SQL 審查

此步驟是為了確保更改：

1. 準(zhǔn)確實現(xiàn)業(yè)務(wù)邏輯；
2. 遵循數(shù)據(jù)庫設(shè)計最佳實踐；

在這里，開發(fā)人員通常負責(zé)前者的任務(wù)，而 DBA 則負責(zé)后者。DevOps 理念旨在通過集成 Ops 和 Devs 來解決這個問題?，F(xiàn)實情況是，當(dāng)組織中存在 DBA 時，很難將兩個團隊直接合并。一種可能的解決方案是保留 DBA 的任務(wù)，同時讓開發(fā)團隊能夠預(yù)審 SQL。這種左移方法可以顯著減少發(fā)布延遲的機會。此外，如果組織中沒有 DBA，那么賦予開發(fā)團隊以確保 SQL 不會對數(shù)據(jù)庫造成嚴重破壞的能力就更加重要。

2、SQL變更執(zhí)行

此步驟是為了確保：

• 語句正確執(zhí)行。我們不希望出現(xiàn)錯誤的數(shù)據(jù)庫連接、權(quán)限不足、對象名稱沖突或基本語法錯誤。
• 所有計劃的語句都被執(zhí)行。當(dāng)要執(zhí)行的腳本很多或者有多個目標(biāo)數(shù)據(jù)庫要批量執(zhí)行時，可能會出現(xiàn)遺漏。
• 變更執(zhí)行過程不應(yīng)影響業(yè)務(wù)。硬件資源耗盡和長時間鎖定表對公司來說并不愉快。

為了避免與變更相關(guān)的錯誤，減少手動方面也很重要：自動化的事情越多，發(fā)生錯誤的機會就越少。預(yù)配置管道以自動將 SQL 應(yīng)用于數(shù)據(jù)庫？聽起來不錯。為避免對常規(guī)業(yè)務(wù)運營產(chǎn)生負面影響，應(yīng)采用各種零停機更改技術(shù)，尤其是對于具有大型數(shù)據(jù)集的數(shù)據(jù)庫。

因此，實施數(shù)據(jù)庫 CI/CD 的關(guān)鍵要素應(yīng)該使開發(fā)團隊能夠執(zhí)行 SQL 審查并簡化 SQL 更改推出。

使用 VCS 集成進行 SQL 審查和變更部署

讓我們首先探討如何讓開發(fā)團隊自己執(zhí)行 SQL 審查。

很少有開發(fā)人員是審查 SQL 語句“架構(gòu)正確性”的專家，即使對于高級 DBA，手動檢查也可能非常低效且容易出錯。幸運的是，業(yè)界通過集成不同的 SQL 檢查規(guī)范創(chuàng)建了各種自動審查工具。

然而，這些工具有一個共同的問題——它們都是為 DBA 設(shè)計的。一方面，這些工具往往需要更高的數(shù)據(jù)庫操作權(quán)限，因此不適合開發(fā)人員直接使用。另一方面，開發(fā)人員擁有自己的 IDE，而單獨的外部仲裁器是他們最不需要的東西。想象一下，當(dāng)您必須在多個工具之間復(fù)制和粘貼代碼時會有多糟糕。

那么開發(fā)人員友好的 SQL 審查工具應(yīng)該是什么樣的呢？

我們通常在版本控制系統(tǒng) (VCS) 上執(zhí)行傳統(tǒng)的代碼審查流程，SQL 也應(yīng)如此。因此，應(yīng)該將 SQL 審查工具集成到代碼審查工作流程中。啟用后，當(dāng)您在 GitHub 上提交 PR 時，將觸發(fā)GitHub Marketplace 上可用的 SQL Review Action 。

讓我們看看如何實現(xiàn)簡化的 SQL 更改推出。

獨立的 SQL 部署工具并不少見。這些工具通常手動上傳 SQL 腳本，通過審批流程繼續(xù)部署，然后在部署完成后提供反饋。該模型準(zhǔn)確地描述了開發(fā)人員和 DBA 如何獨立工作，而分散的流程是延遲發(fā)布的最常見原因之一。畢竟，當(dāng)您在多個系統(tǒng)之間不斷手動移動 SQL 腳本時，誰能保證永遠不會出錯？

我們需要一個更高效和自動化的發(fā)布流程。讓我們回顧一下應(yīng)用程序代碼的經(jīng)典 CI/CD 工作流程：提交更改 > 代碼審查 > 合并分支 > 自動構(gòu)建 > 自動部署。既然我們已經(jīng)在 GitHub Actions 上實現(xiàn)了 SQL 審查，為什么不能包括后續(xù)的推出流程呢？

嗯，是的，我們可以！

用于數(shù)據(jù)庫 CI/CD 的 SQL 更改推出工具應(yīng)該能夠與 VCS 集成。一旦您的 SQL 腳本經(jīng)過審查并合并到目標(biāo)分支中，就會觸發(fā)發(fā)布過程，并且腳本會自動推送到 Bytebase。當(dāng)然，DBA 可以在針對目標(biāo)數(shù)據(jù)庫執(zhí)行 SQL 之前執(zhí)行另一次完整性檢查。

完整的數(shù)據(jù)庫 CI/CD 工作流程

在這里，我們展示了一個完整的數(shù)據(jù)庫 CI/CD 工作流程：

1. 開發(fā)者創(chuàng)建一個包含 SQL 遷移腳本的 Merge Request / Pull Request；
2. 自動觸發(fā) SQL Review Action 來審查 SQL 并提供建議以協(xié)助代碼審查；
3. 經(jīng)過幾次可能的迭代后，開發(fā)團隊中的團隊領(lǐng)導(dǎo)或其他同事批準(zhǔn)更改并將 SQL 腳本合并到一個分支中；
4. 合并事件自動觸發(fā) Bytebase 中的發(fā)布管道，并創(chuàng)建捕獲預(yù)期更改的發(fā)布票；
5. （可選）DBA 或指定的審閱者可以通過 Bytebase 的內(nèi)置 UI 審閱更改腳本；
6. 批準(zhǔn)的腳本會根據(jù)配置的上線階段逐步執(zhí)行；
7. 應(yīng)用更改后，最新的數(shù)據(jù)庫模式會自動寫回代碼存儲庫。這樣一來，開發(fā)團隊始終擁有最新架構(gòu)的副本。此外，他們可以根據(jù)最新模式的變化配置下游管道；
8. 確認遷移并繼續(xù)進行相應(yīng)的應(yīng)用程序推出。

此工作流程非常適合現(xiàn)有的 CI/CD 流程，并且對開發(fā)人員來說很自然。敏銳的讀者可能已經(jīng)發(fā)現(xiàn)所描述的步驟是具有里程碑意義的文章Evolutionary Database Design的實現(xiàn)。