> 作者 YanivYehuda ，譯者 馬德奎 發布于 2014年3月28日 ## 瞬息萬變的世界：敏捷 &DevOps 由于業務需求是變更最主要的驅動者，少做一些，但做得更好，交付更快，這是領先的企業和成功的企業與其他企業的不同之處。 當競爭對手交付了相關功能，速度比你快，質量比你好，那么你最終會喪失市場份額。用投資于銷售和市場營銷活動的方式彌補產品的不足，其代價會很高，而且可能不可靠，而且你可能會發現，客戶轉向了質量卓越的產品。 這正是“敏捷開發”產生的原因：需要更快地采取行動，應對不斷變化的需求（因為我們的目標市場和競爭對手永遠不會靜止不動），可信賴的最佳品質，經常資源不足。敏捷就是源于科技公司和IT部門的期望。 自然地，下一步是找到一個將敏捷應用于生產的方法：連接開發和運維。這就產生了“DevOps”。 運維的主要目標是保證應用程序的穩定和健康，而開發的主要目標是不斷地創新，并提供滿足業務和客戶需求的應用程序。理解這兩點是DevOps發展的關鍵。既然變更是穩定最大的敵人這點沒有疑問，那么理解和調和這種沖突應該是DevOps的主要目標。 為了有效地掌握敏捷沖刺部署以及實施DevOps，人們需要能夠實現部署自動化。否則，部署和發布就需要手動操作步驟和過程，而這些操作并不總是能夠準確地重復，容易出現人為錯誤，并且無法進行高頻率地處理。 處理數據庫部署并不簡單；不像其它軟件組件和代碼或者已編譯的代碼，數據庫不是一個文件集合。那不是可以從開發環境復制到測試環境然后復制到生產環境的東西，因為數據庫是個容器，里面裝了我們最有價值且必須保存的資產——業務數據。它保存了所有應有程序內容、客戶事務處理等。為了促成數據庫變更，需要開發遷移代碼——用于處理數據庫模式結構（表結構）的腳本、數據庫代碼（過程、函數等）和應用程序使用的內容（元數據表、查找內容表或者參數表）。 ## 數據庫變更部署流程的挑戰 應對數據庫挑戰的一個方法是，迫使數據庫變更遵循一般過程：創建數據庫對象的腳本，然后存儲在傳統的版本控制系統中。 那造成了其它的挑戰，包括： 1. 由于是兩個單獨的系統，版本控制系統中的腳本與它們所代表的數據庫對象之間沒有關聯。數據庫代碼的編寫和測試都是在數據庫端完成，脫離了任何最佳編碼實踐（檢入、檢出、標記等），容易出現“舊時代”的所有問題，比如： - 代碼覆蓋在數據庫中很常見，因為沒有什么能夠防止它發生。 - 在數據庫上運行代碼之前，要先從版本控制系統中取得腳本，還要防止工作在錯誤的版本上；但是沒有強制措施可以保證這一點。 - 腳本在版本控制系統中的路徑可能會出錯，因為開發人員靠記憶做這件事。 - 流程之外的更新會被忽視等。 1. 腳本是手動編寫的，容易出現認為錯誤、語法錯誤等等。 1. 為了擁有以后可能需要的一切，開發人員竟然不得不為每個對象保存兩到三個腳本：對象的實際代碼、升級腳本和回滾腳本。 1. 腳本很難進行整體測試。一個人單獨更新了一個對象，而另一個人單獨更新了另一個對象，如果腳本需要以特定的順序運行，那么以任意順序運行通常就會由于錯誤的依賴關系而產生錯誤。 1. 如果一個腳本被開發成代表整個更新而不是單個變更的單獨腳本，那么它可以處理依賴關系，但處理項目范圍的變更就要困難得多了。那是一個很長的命令列表。 1. 除非非常有經驗，否則這些腳本中會缺少從編寫到運行這段時間內發生在目標環境里的變更；可能會覆蓋生產環境中的熱補丁，或者與另一個團隊并行操作。 1. 內容變更管理非常困難。實際上，版本控制系統不適合元數據或者查找內容。在大部分情況下，根本就沒有對它們進行管理。 [ ](http://cdn2.infoqstatic.com/resource/articles/Database-Change-Deployment-Automation/zh/resources/0310020.jpg) 最近十年，出現了另一種理念，就是使用工具處理環境間遷移代碼的生成。這種操作方式被貼上了“**比較****&****同步**”的標簽，是說用一種機械的比較方法檢查源環境中的數據庫對象，并將它與目標環境進行比較，如果發現差異，就會自動生成一個仿照源對象更改目標對象的腳本。在一段時間內，這似乎是個好方法，直到其缺陷變得越來越明顯。 數據庫的比較常常是在選定的檢查點上執行的，通常是在開發周期結束之后，部署之前： 1. 比較工具并不清楚發生在它運行之前的變更，或者任何發生在目標環境中的變更。沒有版本控制，我們就沒有變更信息，只知道特定時間點的差異。 1. 對象腳本保存在傳統的版本控制解決方案中，而部署使用的是比較&同步工具，你可以放開了想象，這兩者之間是如何的無法協同。一個系統對另一個系統一無所知。 1. 手動檢查和關于每個變更的詳細知識必須是部署流程的一部分。否則，下面這樣的不幸就會發生，用過時的代碼或者來自完全從事另外一項工作的團隊的結構覆蓋了生產環境中恰當的、最新的更新（比如由一個開發團隊提供的熱補丁）。 1. 團隊之間的代碼合并完全無法實現。如果需要合并，就需要手動編寫代碼。 手動流程使用“比較&同步”工具還是可以的，但需要熟練和耐心。對數據庫而言，試圖基于這些工具自動化部署流程包含了相當大的風險。 DBA深知數據庫部署的陷阱，同時作為最不合時宜的故障的受害人，往往回避基于上述流程的自動化，因為他們對自動腳本生成器的準確性沒有信心，或者對保證預先準備好的、手動生成的腳本在開發完成后任何時候都依然正確的能力沒有信心。為了避免沖突，他們常常把事情掌握在自己手中。小心翼翼地檢查變更，手動創建盡可能貼合部署活動的變更腳本，相比之下，這種做法似乎不那么令人沮喪。 ## 安全的數據庫部署自動化 通過將數據庫對象變更腳本寫進傳統的版本控制系統中實現自動化的做法有局限性、不靈活、與數據庫本身脫節，而且可能不合標準，并容易因為腳本沖突丟失目標環境的更新。使用“比較&同步”工具實現自動化則是一件有風險的事。這兩種理念沒有結合在一起，一個不知道另一個，必須找出一種更好的解決方案。 為了將數據庫恰當地自動化，必須考慮下列因素： 1. 在**執行一個工作流程**時，有恰當的**數據庫版本控制系統**，應對數據庫獨有的挑戰。這可以防止任何流程外的變更、代碼覆蓋、或者不完整的更新。 1. 利用已經證明了的版本控制**最佳實踐**，獲得關于誰在什么時間因為什么做了什么的完整信息。確保變更的完美記錄是以后部署的基礎。  1. 與**基于任務的開發**相協調，使每個版本控制下的變更與一個變更請求或者一個問題單相關聯。這使得基于任務的部署、部分部署和最后時刻的范圍變更可以在代碼和數據庫之間協調。 1. 確保**配置管理****&****一致性**，這樣，每個開發環境、分支、主干、沙箱以及測試或生產環境都遵循相同的結構、一致的狀態；或者對任何偏差和差異做詳細說明。 1. 處理部署流程自動化的**腳本化**接口能夠在每次執行時提供**可重復**的結果。如果不得不使用用戶界面一次又一次地做同樣的工作，那么即使是最先進的解決方案也會變得繁瑣。 ? 1. 提供**可靠的**部署腳本，能夠解決沖突、合并代碼、以及與其他團隊交叉更新；同時還能忽略錯誤的代碼覆蓋，以及完全集成到版本控制庫。 [ ](http://cdn2.infoqstatic.com/resource/articles/Database-Change-Deployment-Automation/zh/resources/0310022.jpg) 1. 動態提供自動生成的開發腳本，處理部署項目范圍內的任意組合，從多模式的大型更新，到基于單任務的變更及其所依賴的對象。 1. 在變更部署前后，利用“標簽”（標記數據庫結構快照和相關內容）作為安全網，這樣，隨時都可以簡單快速地回滾。 1. 可以完全集成到其它系統（ALM、變更管理/問題單、構建服務器以及發布管理器）。 實現一種能夠應對這些挑戰的解決方案，將使企業能夠實行恰當的數據庫自動化。數據庫自動化很容易與變更和發布流程的其余部分集成，進而實現完整的端到端的自動化。 [ ](http://cdn2.infoqstatic.com/resource/articles/Database-Change-Deployment-Automation/zh/resources/0310023.jpg) ## 總結 數據庫對自動化提出了一個真正的挑戰。將數據庫對象變更腳本寫進傳統的版本控制系統或者使用“比較&同步”工具，對于自動化而言，這兩種理念要么效率不高，要么是件純冒險的事，因為它們彼此之間互不知曉。要以數據庫DevOps的形式實現一種更好的解決方案。 數據庫DevOps應該遵循已經證明了的變更管理最佳實踐，在數據庫上強制實行單一的變更流程，能夠解決部署沖突，降低代碼覆蓋、交叉更新和代碼合并的風險，同時能夠插入到發布流程的其余部分。 ## 關于作者 **YanivYehuda**是[DBmaestro](http://www.dbmaestro.com/)的聯合創始人和CTO，這是一家專注于數據庫開發和部署技術的企業級軟件開發公司。Yaniv還是ExtremeTechnology的聯合創始人和開發主管，這是一家面向以色列市場的IT服務提供商。Yaniv曾經是以色列國防軍計算機中心Mamram的一名上尉，他在那里擔任軟件工程經理。 **查看英文原文：**[**TheSecrets of Database Change Deployment Automation**](http://www.infoq.com/articles/Database-Change-Deployment-Automation) 查看原文：[數據庫變更部署自動化秘訣](http://www.infoq.com/cn/articles/Database-Change-Deployment-Automation)