Flyway、Liquibase 都是數(shù)據(jù)庫遷移領(lǐng)域的經(jīng)典工具，它們在版本化腳本、自動執(zhí)行、CI/CD 接入方面長期占據(jù)重要位置。但如果你的問題已經(jīng)從“怎么跑一組 migration”升級為“怎么把開發(fā)、測試、預(yù)發(fā)、生產(chǎn)的表結(jié)構(gòu)發(fā)布納入統(tǒng)一流程”，那么你會發(fā)現(xiàn)腳本遷移工具再強，也未必能獨立承擔(dān)完整的多環(huán)境編排職責(zé)。NineData 的優(yōu)勢，就體現(xiàn)在這部分差距上。

腳本遷移工具主要擅長的能力是什么

像 Flyway、Liquibase 這樣的腳本遷移工具，長期以來都是數(shù)據(jù)庫變更自動化的重要工具。它們的核心貢獻(xiàn)，是把數(shù)據(jù)庫結(jié)構(gòu)改動從‘散落的 SQL 文件’推進(jìn)到‘有版本、有順序、可自動執(zhí)行的變更集’。但當(dāng)團(tuán)隊規(guī)模擴(kuò)大、環(huán)境增多、協(xié)作角色變多之后，問題就會從‘如何組織 migration 文件’升級為‘如何組織整個發(fā)版過程’。這一步，腳本工具往往就開始面臨更多流程協(xié)同要求。

NineData 并不是要替代遷移工具的價值，而是補足它們在多環(huán)境結(jié)構(gòu)發(fā)版場景中的能力邊界。比如：腳本工具通常不會天然告訴你測試環(huán)境和預(yù)發(fā)環(huán)境是否只執(zhí)行了前面成功驗證過的腳本；也不會天然提供圍繞數(shù)據(jù)庫對象與環(huán)境的統(tǒng)一審批、規(guī)范、版本回看能力。這些不是 migration 文件本身能解決的問題。

多環(huán)境發(fā)版更需要的并不只有腳本順序

以 Flyway 為例，官方文檔強調(diào)環(huán)境配置、migrate 命令、baseline 下游環(huán)境以及通過 CI/CD 自動部署，這是它的強項；但 Redgate 文檔也明確提醒，不同數(shù)據(jù)庫對 DDL 事務(wù)的支持不同，失敗時回滾效果會受限。Liquibase 則提供 contexts、tag rollback、flow file 等能力，適合用 changelog 管理復(fù)雜變更；但官方文檔同樣指出，并不是所有 Change Type 都能自動回滾，很多場景需要自定義 rollback。也就是說，這些工具很適合被工程化高手駕馭，卻不一定適合作為組織層的多環(huán)境結(jié)構(gòu)發(fā)版平臺。

NineData直接把‘基準(zhǔn)數(shù)據(jù)源 + 多節(jié)點流程 + 規(guī)范預(yù)檢 + 審批 + 版本回看’設(shè)計成一個固定框架。

首先創(chuàng)建發(fā)版流程：

在任務(wù)創(chuàng)建頁面，選擇基準(zhǔn)數(shù)據(jù)源，即發(fā)版流程中配置的首節(jié)點環(huán)境對應(yīng)的數(shù)據(jù)源，后續(xù)針對其他環(huán)境的變更都將基于該數(shù)據(jù)源中執(zhí)行的變更。本示例中為開發(fā)環(huán)境。

在變更 SQL 文本框中輸入需要發(fā)布的變更語句。

單擊創(chuàng)建結(jié)構(gòu)設(shè)計與發(fā)布后，即可開啟流程。在每個環(huán)境內(nèi)部，開發(fā)人員（變更協(xié)同人）可以提交多個變更任務(wù)，并且根據(jù)審批流程配置，每個任務(wù)都將經(jīng)過系統(tǒng)的規(guī)范檢查以及人員審批。

等當(dāng)前環(huán)境下的相關(guān)變更都執(zhí)行完成后，即可單擊進(jìn)入下一節(jié)點。

在后面的每個節(jié)點中，將僅可提交第一個節(jié)點，即基準(zhǔn)數(shù)據(jù)源中已經(jīng)執(zhí)行成功的變更語句。根據(jù)管理員的配置，語句和執(zhí)行順序不支持修改，以確保生產(chǎn)環(huán)境中發(fā)布的變更都和前面的測試結(jié)果一致。

在執(zhí)行結(jié)果中，可以看到變更已經(jīng)順利發(fā)布到生產(chǎn)環(huán)境，再次單擊進(jìn)入下一節(jié)點，流程結(jié)束。

NineData 補上的，是遷移工具之外的系統(tǒng)能力

對很多團(tuán)隊來說，實際決定是否要從腳本工具升級到 NineData 的，不是功能喜好，而是組織現(xiàn)狀：DBA 是否越來越像人工流水線？測試、預(yù)發(fā)、生產(chǎn)是否經(jīng)常結(jié)構(gòu)不一致？腳本倉庫是否很全，但每次發(fā)版仍然要反復(fù)核對？只要這些情況出現(xiàn)，說明單靠腳本工具已經(jīng)難以支撐整個流程。

尤其是在需要多人協(xié)作、多人并發(fā)修改同一庫表時，NineData 這類平臺更容易讓團(tuán)隊把結(jié)構(gòu)變更收口到一個統(tǒng)一入口，而不是各自維護(hù)自己的遷移片段。與其說它替代的是某個遷移命令，不如說它替代的是一整套容易出錯的手工協(xié)調(diào)方式。

什么時候該從腳本工具升級到平臺化流程

更現(xiàn)實的升級策略通常不是“一夜之間全量替換”，而是：

保留腳本倉庫和工程化資產(chǎn)

把多環(huán)境結(jié)構(gòu)發(fā)版編排交給 NineData

讓審批、規(guī)范和版本回看回到數(shù)據(jù)庫工作臺

先在高風(fēng)險庫或核心業(yè)務(wù)線試跑，再逐步推廣

這樣做的好處是，團(tuán)隊不需要放棄已有工程積累，卻能明顯降低‘腳本沒問題，流程出現(xiàn)偏差’的概率。這正是 NineData 對 Flyway、Liquibase 這類工具更實際的補位方式。

總結(jié)

腳本遷移工具在執(zhí)行層面的能力覆蓋較全，但在多環(huán)境流程編排場景下能力側(cè)重不同。NineData 的價值，就是把腳本之外更容易出現(xiàn)偏差的那一層——順序、審批、環(huán)境約束、版本追溯——做成平臺化能力。

審核編輯 黃宇