[[403541]]

【51CTO.com快譯】近年來，一種被稱為DevOps的軟件工程文化已悄然在許多組織中流行起來。它旨在統(tǒng)一軟件開發(fā)(Dev)和IT運營(Ops)，并且通過持續(xù)集成(CI)和持續(xù)交付(CD)兩個主要概念，在軟件工程的實踐中倡導(dǎo)自動化。如今，許多應(yīng)用開發(fā)團隊都能夠從此類敏捷開發(fā)的實踐中實現(xiàn)：頻繁的軟件交付，盡早地收到客戶的反饋，擁有組織內(nèi)跨職能的團隊，更快地讓產(chǎn)品面市，以及保持客戶的滿意度。

不過傳統(tǒng)的數(shù)據(jù)庫手動變更管理過程，正在逐漸成為持續(xù)交付的瓶頸。對此，本文將重點討論如何將其簡化到應(yīng)用代碼的統(tǒng)一交付管道中。

持續(xù)集成

作為敏捷開發(fā)過程的核心原則之一，持續(xù)集成強調(diào)的是確保由團隊內(nèi)多個成員所開發(fā)出的代碼，能夠順暢實現(xiàn)集成，進而避免出現(xiàn)各自為政的“集成地獄”。它主要涉及到獨立且自動化的構(gòu)建、以及自動化的測試?？梢哉f，持續(xù)集成促進了以測試為驅(qū)動的開發(fā)，以及對版本控制系統(tǒng)的基線、主分支、主干(trunk)的頻繁“原子性”提交的實踐。

圖1：典型的持續(xù)集成過程

如上圖所示，開發(fā)人員一旦將代碼簽入源控制系統(tǒng)，就會觸發(fā)在持續(xù)集成服務(wù)器中的配置構(gòu)建作業(yè)。該作業(yè)將從版本控制系統(tǒng)中簽出代碼，進行構(gòu)建，執(zhí)行測試，并將生成的工件(如jar文件)，部署到工件存儲庫(artifact repository)中。一部分定時觸發(fā)的CI作業(yè)，則會將代碼部署到開發(fā)環(huán)境中，將詳細信息推送到靜態(tài)分析工具中，對已部署的代碼、或團隊認為實用的自動化過程進行系統(tǒng)測試，進而確保代碼庫的運行狀況良好。同時，敏捷團隊有責(zé)任確保上述自動化流程在出現(xiàn)任何失敗時，能夠暫緩代碼的提交，直至自動化的構(gòu)建被修復(fù)。

持續(xù)交付

持續(xù)交付除了需要確保軟件系統(tǒng)中的不同模塊能夠被始終集成之外，還要確保代碼能夠始終被部署到生產(chǎn)環(huán)境中。這意味著，系統(tǒng)除了擁有自動化的構(gòu)建和測試套件之外，還具有自動化的交付過程。通常，我們只需單擊按鈕，便可在幾分鐘之內(nèi)完成軟件的部署。同樣作為DevOps的核心原則，持續(xù)交付的優(yōu)勢包括：可預(yù)測的部署，降低引入新功能的風(fēng)險，縮短客戶反饋的周期，以及提高軟件的總體質(zhì)量。

圖2：典型的連續(xù)交付過程

“持續(xù)交付”的過程往往基于“持續(xù)集成”過程之上。上圖包含了用戶驗收測試(UAT)和生產(chǎn)兩種環(huán)境。不過，在軟件進入生產(chǎn)環(huán)境之前，不同的組織可能會設(shè)有諸如：質(zhì)量保證(QA)、負載測試、預(yù)生產(chǎn)等多個staging(模擬)環(huán)境。當(dāng)然，所有staging環(huán)境和生產(chǎn)環(huán)境的部署，都是通過相同的自動化過程來執(zhí)行的，并且采用的是不同環(huán)境的相同版本代碼庫。我們可以使用多種工具來實現(xiàn)配置的自動化、受控、可重復(fù)、可靠、可審核、以及可逆(或稱可回滾)。

數(shù)據(jù)庫變更管理的瓶頸問題

不可否認，幾乎所有的項目除了交付已開發(fā)的應(yīng)用代碼，也會涉及到諸如schema(結(jié)構(gòu)模式)變更等與數(shù)據(jù)庫相關(guān)的工作。目前，我們認為在數(shù)據(jù)庫的開發(fā)領(lǐng)域尚未采用敏捷原則，或?qū)崿F(xiàn)持續(xù)集成。因此，此類數(shù)據(jù)庫的相關(guān)工作會或多或少地拖慢整個軟件產(chǎn)品的交付進程。

讓我來看一個真實的案例。某開發(fā)團隊通過遵循Scrum的敏捷方式，進行了2周的sprint(迭代)。當(dāng)前的一條story(故事線)是在文檔中添加一個能與下游系統(tǒng)交互的新字段。開發(fā)團隊估計：就代碼開發(fā)而言，業(yè)務(wù)事件觸發(fā)應(yīng)用會將文檔發(fā)送到下游系統(tǒng)，以及后期的檢索系統(tǒng)，這些僅涉及到數(shù)據(jù)訪問層中的微小變更。因此，如果不涉及數(shù)據(jù)庫(本例為關(guān)系數(shù)據(jù)庫管理系統(tǒng))的變更，這個僅向現(xiàn)有數(shù)據(jù)表中添加新列的story，很容易在當(dāng)前的sprint中被實現(xiàn)。但是，正是因為涉及到數(shù)據(jù)庫的修改，開發(fā)團隊可能會對此類迭代的可行性缺乏信心。

這是為什么呢?其原因在于，他們需要將架構(gòu)的變更請求發(fā)送給數(shù)據(jù)庫管理員(DBA)。而DBA將會花時間去確定該變更請求的優(yōu)先級，并將它與從其他開發(fā)團隊處收到的變更請求進行比較。而在開發(fā)數(shù)據(jù)庫完成了變更以后，DBA則會通知開發(fā)人員，并等待他們的反饋，以便將變更推廣到QA或其他階段的環(huán)境中。同時，開發(fā)人員將測試新架構(gòu)中代碼的變更。最后，通過開發(fā)團隊與DBA的緊密協(xié)調(diào)，將應(yīng)用的變更和數(shù)據(jù)庫的變更共同交付到生產(chǎn)環(huán)境中。

圖3：交付數(shù)據(jù)庫變更的手動與半自動過程

值得注意的是，在上圖中，該過程并非由開發(fā)人員檢入代碼而觸發(fā)的，而是需要兩個團隊之間的交互。也就是說，即使數(shù)據(jù)庫側(cè)的部署過程是自動化的，也無法與應(yīng)用代碼的交付管道集成在一起。雖說應(yīng)用代碼的變更在某種程度上直接取決于數(shù)據(jù)庫的變更，但是這兩個變更的生命周期是完全相互獨立的。

下面，讓我們來討論如何將那些與數(shù)據(jù)庫變更相關(guān)的工作(包括數(shù)據(jù)建模和schema變更等)置于CI/CD過程的范疇之內(nèi)。

DBA應(yīng)該成為跨職能敏捷團隊的一部分

許多組織會根據(jù)：協(xié)助建立應(yīng)用開發(fā)的數(shù)據(jù)庫，以及維護生產(chǎn)環(huán)境的數(shù)據(jù)庫，來區(qū)分DBA的角色。其中，服務(wù)于生產(chǎn)環(huán)境的DBA的主要職責(zé)是：通過監(jiān)控數(shù)據(jù)庫，處置升級與補丁，分配存儲空間，執(zhí)行備份與恢復(fù)等，以確保生產(chǎn)環(huán)境中數(shù)據(jù)庫的可用性。而開發(fā)類DBA需要與應(yīng)用開發(fā)團隊緊密合作，估計存儲需求，并協(xié)助他們進行數(shù)據(jù)模型的設(shè)計，將邏輯模型轉(zhuǎn)換為數(shù)據(jù)庫的物理schema等。

可見，為了將數(shù)據(jù)庫的工作和應(yīng)用開發(fā)工作整合到一個交付管道中，我們勢必讓開發(fā)類DBA成為開發(fā)團隊的一部分，并由具有良好數(shù)據(jù)庫知識的全棧開發(fā)人員來擔(dān)任。

數(shù)據(jù)庫作為代碼(Database As Code)

為了實現(xiàn)將數(shù)據(jù)庫變更和應(yīng)用代碼集成到單個管道中，我們需要對數(shù)據(jù)庫中的每一項變更編寫腳本，并對其予以版本控制，進而按需通過腳本自動建立一個新的數(shù)據(jù)庫實例。如果我們必須將數(shù)據(jù)庫的對象捕獲為代碼，那么需要根據(jù)腳本(即代碼)的類型，對數(shù)據(jù)庫進行評估與分類。具體區(qū)別標(biāo)準(zhǔn)如下：

數(shù)據(jù)庫結(jié)構(gòu)：

就是我們經(jīng)常提到的schema(模式)，它定義了數(shù)據(jù)庫存儲數(shù)據(jù)的結(jié)構(gòu)，其中包括針對表、視圖、約束、索引和類型的定義。數(shù)據(jù)字典也可以被視為數(shù)據(jù)庫結(jié)構(gòu)的一部分。

已存儲的代碼：

它們與應(yīng)用代碼非常相似，其不同之處在于，它們被存儲在數(shù)據(jù)庫中，并由數(shù)據(jù)庫引擎來執(zhí)行。它們包括：存儲過程、函數(shù)、程序包、以及觸發(fā)器等。

參考數(shù)據(jù)：

它們通常存儲著被其他業(yè)務(wù)數(shù)據(jù)表所引用的一組允許值(permissible values)。在理想情況下，參考數(shù)據(jù)表中幾乎沒有數(shù)據(jù)記錄。它們只有在某些業(yè)務(wù)流程發(fā)生變更時，才可能跟著變化，而在正常業(yè)務(wù)過程中是不會發(fā)生變更的。

應(yīng)用數(shù)據(jù)或業(yè)務(wù)數(shù)據(jù)：

它們是應(yīng)用程序在正常業(yè)務(wù)過程中產(chǎn)生的數(shù)據(jù)記錄，這是任何數(shù)據(jù)庫被加入到應(yīng)用系統(tǒng)的主要目的。

總的說來，在以上四種類型的數(shù)據(jù)庫對象中，前三種可以并且應(yīng)該被捕獲為腳本，進而被存儲在版本控制系統(tǒng)中。

表1：是否可被編寫為腳本的數(shù)據(jù)庫對象類型

如上表所示，業(yè)務(wù)或應(yīng)用數(shù)據(jù)是唯一不能被腳本化、或存儲為代碼的類型。所有回滾、修改、歸檔等都是由數(shù)據(jù)庫本身來執(zhí)行的。唯一例外的是，當(dāng)schema變更導(dǎo)致數(shù)據(jù)發(fā)生遷移時(例如，填充了新的列，或?qū)?shù)據(jù)從基表移至規(guī)范化表中)，遷移腳本將被視為代碼，并且應(yīng)當(dāng)遵循與schema變更相同的生命周期。

下面，讓我們以一個簡單的數(shù)據(jù)模型為例(您可以認為數(shù)據(jù)建模的“Hello World”)，來說明如何將腳本存儲為代碼。

圖4：該示例模型中包含了業(yè)務(wù)數(shù)據(jù)表和參考數(shù)據(jù)表

在上述模型中，客戶可能與諸如：帳單地址、送貨地址等多個地址相關(guān)聯(lián)。AddressType表存儲了諸如：帳單、送貨、住所、工作等不同類型的地址。存儲在AddressType中的數(shù)據(jù)可以被視為參考數(shù)據(jù)，畢竟它們在日常業(yè)務(wù)運營中不會有激增。而其他包含著業(yè)務(wù)數(shù)據(jù)的表，會隨著客戶的增多，而繼續(xù)增長。

下面是各種示例腳本：

表：

限制條件：

參考數(shù)據(jù)：

由上述示例可知，除了業(yè)務(wù)數(shù)據(jù)，其他所有的數(shù)據(jù)庫對象都能夠被捕獲到SQL腳本中。

與應(yīng)用代碼位于同一存儲庫中的版本控制數(shù)據(jù)庫工件：

將數(shù)據(jù)庫工件與應(yīng)用代碼保存到版本控制系統(tǒng)的同一存儲庫中，有著諸多好處。由于在大多數(shù)情況下，數(shù)據(jù)庫schema的變更往往會涉及到應(yīng)用代碼的變更，因此將它們標(biāo)記為共同發(fā)布，可以避免應(yīng)用代碼和數(shù)據(jù)庫出現(xiàn)不同步的狀況。同時，由于與項目相關(guān)的所有內(nèi)容都放在了一處，因此新的團隊成員可以更加輕松方便的獲悉與查閱，進而加快了工作效率。

圖5：包含了數(shù)據(jù)庫代碼的Java Maven項目的結(jié)構(gòu)示例

上面的目錄結(jié)構(gòu)展示了如何在Java Maven項目中，將數(shù)據(jù)庫腳本與應(yīng)用代碼一起存儲。當(dāng)然，這對于Ruby或.Net等應(yīng)用，也是通用的。CI/CD自動化工具可以在同一處找到它們，并對其執(zhí)行諸如：從頭開始構(gòu)建架構(gòu)、生成遷移、以及產(chǎn)生部署腳本等必要的操作。

將數(shù)據(jù)庫工件集成到構(gòu)建腳本中：

為了確保數(shù)據(jù)庫的變更能夠與同一交付管道中的應(yīng)用代碼“齊頭并進”，我們在構(gòu)建的過程中包含數(shù)據(jù)庫腳本是非常必要的。通常，數(shù)據(jù)庫工件是某種形式的SQL腳本，而且大多數(shù)主流構(gòu)建工具都能夠支持本地、或通過插件的方式執(zhí)行SQL腳本。

在此，讓我們先討論在本地環(huán)境、或CI服務(wù)器中的構(gòu)建，稍后再涉及到暫存環(huán)境。其中包括的典型任務(wù)包括：

• 刪除Schema。
• 創(chuàng)建Schema。
• 創(chuàng)建數(shù)據(jù)庫結(jié)構(gòu)(或Schema對象)，包括表、約束、索引、序列和同義詞。
• 部署已存儲的代碼，包括過程、函數(shù)、以及包等。
• 加載參考數(shù)據(jù)。
• 加載測試數(shù)據(jù)。

構(gòu)建工具可以確保數(shù)據(jù)庫在加載已知數(shù)據(jù)集時處于穩(wěn)定的狀態(tài)，并且通過充分的集成測試，以避免出現(xiàn)應(yīng)用代碼與數(shù)據(jù)模型的不同步。這是在數(shù)據(jù)庫變更管理過程中，實現(xiàn)持續(xù)交付模型的第一步。

圖6：該代碼片段展示了用于運行數(shù)據(jù)庫腳本的Maven構(gòu)建

上面的代碼截圖說明了如何使用Maven插件來運行SQL腳本。它能夠刪除與重建schema，并通過運行所有的DDL腳本，來創(chuàng)建表、約束、索引、序列和同義詞。接著，它將所有已存儲的代碼部署到數(shù)據(jù)庫中，并最后加載所有的參考數(shù)據(jù)和測試數(shù)據(jù)。

避免共享數(shù)據(jù)庫

讓多個應(yīng)用共享一個數(shù)據(jù)庫schema并非一個好主意。除非數(shù)據(jù)庫真正屬于某個應(yīng)用、且不被其他應(yīng)用所共享，否則將應(yīng)用代碼和數(shù)據(jù)庫變更置于同一交付管道下，將難以達到預(yù)期的效果。同時，共享數(shù)據(jù)庫還會導(dǎo)致應(yīng)用之間的緊密耦合、以及許多其他問題。

讓每個提交和CI服務(wù)器都能專享Schema

開發(fā)人員總希望能夠在自己的“沙箱”中工作，而不必擔(dān)心諸如開發(fā)數(shù)據(jù)庫實例之類通用環(huán)境等問題。而CI服務(wù)器就是這樣的沙箱，它遵循了如何開發(fā)應(yīng)用代碼的模式。開發(fā)人員可以執(zhí)行各種變更，在本地運行構(gòu)建，并且在構(gòu)建成功且測試通過后，再提交變更。通常，此類沙盒既可以是在開發(fā)人員本地電腦上、已安裝的獨立數(shù)據(jù)庫實例，也可以是共享數(shù)據(jù)庫實例中的其他架構(gòu)。

圖7：開發(fā)人員在其本地環(huán)境中進行頻繁的變更與提交

如上圖所示，每個開發(fā)人員都擁有自己的schema副本。在執(zhí)行完成構(gòu)建之后，除了構(gòu)建應(yīng)用，它還會從頭開始構(gòu)建數(shù)據(jù)庫的schema。其中包括：刪除與重建schema，執(zhí)行DDL腳本，以加載所有的schema對象(如：表、視圖、序列、約束和索引)。同時，它會創(chuàng)建代表著已存儲的代碼對象，其中包括：函數(shù)、過程、包和觸發(fā)器。最后，它將加載所有的參考數(shù)據(jù)和測試數(shù)據(jù)。而自動化的測試則可確保應(yīng)用代碼和數(shù)據(jù)庫對象始終同步。值得注意的是，由于數(shù)據(jù)模型的變更不如應(yīng)用代碼那樣頻繁，因此出于構(gòu)建性能的考慮，我們應(yīng)當(dāng)讓構(gòu)建腳本應(yīng)具有跳過數(shù)據(jù)庫構(gòu)建的選項。

其實，CI構(gòu)建作業(yè)也應(yīng)當(dāng)被設(shè)置為帶有自己的數(shù)據(jù)庫沙箱。畢竟，構(gòu)建腳本會執(zhí)行完整的構(gòu)建，其中就包括了構(gòu)建應(yīng)用，以及從頭開始構(gòu)建數(shù)據(jù)庫的schema。而且，它會運行一整套的自動化測試，以確保應(yīng)用本身、及其與之交互的數(shù)據(jù)庫能夠保持同步。

圖8：修改后的CI流程，集成了數(shù)據(jù)庫構(gòu)建和應(yīng)用代碼的構(gòu)建

上圖中描述的過程與圖1中的過程較為相似。CI服務(wù)器包含了在對存儲庫提交時觸發(fā)的構(gòu)建作業(yè)。它所執(zhí)行的構(gòu)建包含了應(yīng)用和數(shù)據(jù)庫的構(gòu)建。至此，數(shù)據(jù)庫腳本就能夠被整合為應(yīng)用代碼了。

處置遷移

我們在前文中已經(jīng)討論了如何針對持續(xù)集成和本地環(huán)境，從頭開始構(gòu)建數(shù)據(jù)庫的schema對象、已存儲的代碼、參考數(shù)據(jù)和測試數(shù)據(jù)。那么對于生產(chǎn)環(huán)境中的數(shù)據(jù)庫、以及QA或UAT環(huán)境又該如何處理呢?

鑒于數(shù)據(jù)庫的本質(zhì)就是為了支持業(yè)務(wù)數(shù)據(jù)，我們不可能對當(dāng)前正在運行的業(yè)務(wù)交易數(shù)據(jù)庫，采取刪除schema、或從腳本中重建等操作。因此，我們需要編寫增量腳本，也就是將數(shù)據(jù)庫的結(jié)構(gòu)從已知的狀態(tài)(所謂“軟件定制版”)變更過渡，或?qū)?shù)據(jù)遷移到所需的狀態(tài)。例如，為了標(biāo)準(zhǔn)化，我們可能需要通過腳本將一個表中的數(shù)據(jù)遷至一到多個子表中。而schema的變更，則可以在源代碼存儲庫中，通過腳本的編寫，使其成為構(gòu)建的一部分。這些腳本既可以在主動開發(fā)的過程中手工被編寫，也可以由一些自動化工具來完成。其中的一種工具是Flyway，它可以生成遷移腳本，將數(shù)據(jù)結(jié)構(gòu)從一種狀態(tài)轉(zhuǎn)換為另一種狀態(tài)。Schema的變更可以在源代碼存儲庫中被編寫腳本并進行維護，以使它們成為構(gòu)建的一部分。

圖9：schema遷移與回滾的自動化

在上圖中，左側(cè)顯示了與應(yīng)用先前版本(1.0.1)同步的數(shù)據(jù)庫狀態(tài)。右側(cè)顯示了數(shù)據(jù)庫所需的下一版本狀態(tài)。我們在版本控制系統(tǒng)中既可以捕獲并標(biāo)記左側(cè)的狀態(tài)，又可以將捕獲到的右側(cè)狀態(tài)作為基線、主分支或主干。兩者之間的區(qū)別正是我們需要讓數(shù)據(jù)庫在staging環(huán)境和生產(chǎn)環(huán)境中保持不同的狀態(tài)。上圖展示了Flyway工具通過創(chuàng)建遷移腳本，將數(shù)據(jù)庫從先前的版本過渡到新的版本;以及通過回滾腳本，將數(shù)據(jù)庫過渡回先前版本的自動化過程。這些生成的腳本將會被標(biāo)記，并與其他部署工件一起被存儲。因此，我們通過將該自動化過程與持續(xù)交付的過程相集成，以確?？芍貜?fù)、可靠、且可逆(通過回滾)的數(shù)據(jù)庫變更。

將數(shù)據(jù)庫變更并入連續(xù)交付

現(xiàn)在，我們可以將上述各部分整合到一起了，即：通過一個現(xiàn)有的持續(xù)集成過程，來重建數(shù)據(jù)庫和應(yīng)用代碼;通過一個并入部署工件的過程，為數(shù)據(jù)庫生成遷移腳本。DevOps工具將使用這些已發(fā)布的工件，來構(gòu)建任何staging環(huán)境或生產(chǎn)環(huán)境。該部署工件還將包含回滾腳本，以便在出現(xiàn)任何問題時，我們都可以重新部署應(yīng)用的先前版本，通過運行數(shù)據(jù)庫的回滾腳本，將數(shù)據(jù)庫的schema轉(zhuǎn)換為與應(yīng)用代碼的先前版本相同步的狀態(tài)。

圖10：包含了數(shù)據(jù)庫變更的持續(xù)交付

上圖描述了將數(shù)據(jù)庫變更管理并入持續(xù)交付的過程。此處假設(shè)已經(jīng)存在一個持續(xù)集成過程。在啟動了UAT(或測試、QA等其他staging環(huán)境)的部署后，自動化流程將負責(zé)在源代碼控制存儲庫中創(chuàng)建標(biāo)簽，并從帶標(biāo)簽的代碼庫中構(gòu)建可部署的應(yīng)用工件，生成數(shù)據(jù)庫遷移腳本，組裝工件，并執(zhí)行部署。整個部署的過程包括：應(yīng)用的部署，以及將遷移腳本應(yīng)用到數(shù)據(jù)庫中。按照審批流程，應(yīng)用程序會通過相同的工件被部署到生產(chǎn)環(huán)境中。若要回滾至先前版本，則需重新部署應(yīng)用程序，并運行數(shù)據(jù)庫的回滾腳本。

市場上的可用工具

前面我們主要介紹了如何在涉及數(shù)據(jù)庫變更的項目中，實現(xiàn)CI/CD的過程。而在實踐中，我們往往會根據(jù)不同的需求，使用不同的工具，例如：針對構(gòu)建自動化的Maven或Gradle，針對持續(xù)集成的Jenkins或TravisCI，以及針對配置管理的Chef或Puppet等本地解決方案。下面，我為您羅列出針對數(shù)據(jù)庫DevOps的自動化通用工具：

• Datical 
• Redgate 
• Liquibase 
• Flyway 

小結(jié)

誠然，持續(xù)集成和持續(xù)交付的流程為組織帶來了諸如：縮短產(chǎn)品的面市時間，可靠的發(fā)布，以及提高軟件整體質(zhì)量等巨大的好處。鑒于手動執(zhí)行數(shù)據(jù)庫變更管理會帶來的交付瓶頸，本文和您討論了如何將數(shù)據(jù)庫的變更，帶入與應(yīng)用代碼相同的交付管道中，以及市場上能夠配合此類實踐的各種實用工具。

原文標(biāo)題：Continuous Integration and Continuous Delivery for Database Changes，作者: Ashoke Bhowmick

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】