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

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

但它是如何工作的？

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

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

1. SQL 審查

此步驟是為了確保更改：

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

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

2、SQL變更執(zhí)行

此步驟是為了確保：

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

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

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

使用 VCS 集成進(jìn)行 SQL 審查和變更部署

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

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

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

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

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

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

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

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

嗯，是的，我們可以！

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

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

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

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

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