作者介紹

[[162538]] 

　　徐桂林，當前在FIT2CLOUD負責公司的技術布道和生態合作。在此之前先后供職于意法半導體、Autodesk和阿里云。徐桂林熱衷于云計算(尤其是公有云IaaS平臺)，有過多年AWS的生產環境工作經歷，是較早在國內分享AWS上實踐經驗的作者之一。

　　需不需要一個獨立的部署系統是很多企業用戶在構建持續交付流程中經常困惑的一個問題。也經常有用戶會問我們，現在已經有Jenkins，它自身提供了豐富的部署插件(如WebSphere部署插件、Tomcat部署插件等)，方便用戶直接把構建出來的部署包自動化部署到指定機器(甚至云服務)。那為什么不可以圍繞Jenkins，集成一系列部署流程，從而不需要額外搭建一個獨立的部署系統?

　　注：本文以Jenkins為例來說明獨立部署系統的重要性。但持續構建工具不僅僅限制于Jenkins，還包括如BuildForge、TeamCity、CruiseControl等，而它們和獨立部署系統的關系與Jenkins基本都一致。

　　持續交付與部署系統

　　上面提出了一個非常好的問題，但是要回答這個問題，我們需要從更大的視角(即持續交付)來理解一個部署系統需要扮演的角色，而不僅僅從自動化部署過程這一點(盡管這一點也非常重要)來理解它。首先，讓我們看看軟件生產中從代碼到最終服務的典型流程(如下圖)。

　　從上圖中可以看出，從開發人員寫下代碼到服務最終用戶是一個漫長過程，整體可以分成三個階段：

　　1.從代碼(Code)到制品庫(Artifact)：這個階段主要對開發人員的代碼做持續構建并把構建產生的制品集中管理，是為部署系統準備輸入內容的階段。

　　2.從制品到可運行服務：這個階段主要完成制品部署到指定環境，是部署系統的最基本工作內容。

　　3.從開發環境到最終生產環境：這個階段主要完成一次變更在不同環境的遷移，是部署系統上線最終服務的核心能力。

　　如果從持續交付角度看，其最核心訴求就是要讓上圖三個階段能夠無縫連接并自動化運行起來，從而達到持續交付的兩個核心目標：提高交付頻率(部署次數)和降低部署延時(從代碼提交到上線的時間差)。

　　持續交付對部署系統的要求

　　參照如上持續交付的流程，可以發現持續交付對于一個部署系統的要求絕對不僅僅是一個自動化的部署過程，這也是在有了Jenkins和其相關部署插件后仍然需要搭建獨立部署系統的原因所在。具體來說，我們可以從下面幾點分析：

　　1.解耦構建和部署過程

　　盡管持續交付希望自動化完成從代碼到部署上線的整個流程。但是整個持續交付過程有多個不同角色的人參與其中(開發、測試、運維甚至還有經理及市場人員)。其中，有些角色(如開發/測試)需要關心構建過程，而更多的角色(如運維等)絕大時候都是從制品開始部署工作。這也就要求構建和部署過程相互解耦，能夠獨立操作。

　　如果基于Jenkins直接觸發部署，要直接綁定構建和部署過程。構建和部署這兩個過程通過制品(Artifact，又稱為部署包)連接(制品是構建過程的產出，同時是部署過程的輸入)。如果它們相互解耦，自然就需要有統一的地方管理存儲和管理這些制品，即統一制品庫。

　　有了統一制品庫后，構建過程自動提交產生的制品到此，而部署過程則主動到制品庫拉取需要的制品進行部署，從而實現構建和部署的完整解耦。

　　2.管理復雜的部署環境

　　如前所述，服務上線需要涉及到很多不同目的環境(開發、測試、預發、生產、演示等)。而且，在越來越多的云化基礎設施中，環境內部的資源會頻繁變化(例如，Auto-Scaling時刻都有可能添加或者減少你的云主機)。

　　這時候需要對部署流程隔離部署環境差異以及環境內頻繁變化的基礎設施。當需要執行一個部署時，操作人員只需要指定部署到哪個環境(即環境名稱或者ID號)，而不需要關心環境內部的任何信息。

　　由部署系統負責把部署請求分發到指定環境內的每臺主機并自動執行。如果基于Jenkins來直接部署，則必然把環境管理的很多復雜度引入到部署流程內部。

　　3.支持多種部署策略

　　為保障服務的高可用，落實部署和發布的解耦以及其他業務需要，用戶常需要支持如灰度發布、A/B測試發布等部署需求。一個獨立的部署系統在此可以提供多種部署策略，并結合環境管理等其他功能滿足業務上對部署和發布的各種需求。同樣，Jenkins及其部署插件并沒有提供這樣的能力。

　　4.落實部署流程規范

　　在一個公司內部經常有不同的項目，使用不同的編程語言，而部署流程也五花八門。從控制風險，減少重復操作，降低部署自動化難度等多重考量，公司都傾向制定一套標準的部署流程。

　　這時候，獨立的部署系統就可以幫助用把這些規范落實下去并在日常的部署過程中時刻校驗(在軟件工程領域，幾乎所有的規范落實都得靠工具來助一臂之力，否則基本都會變成紙面上的規范而已)。

　　如果基于Jenkins來直接部署，如何落實這些部署規范仍然是一個很困難的事情，因為Jenkins及其部署插件并未對此提供任何實質性的支持。

　　5.獲取部署運營數據

　　部署是一個團隊從代碼到服務的關鍵路徑，這上面的所有操作數據都值得記錄并用于各種運營支持(包括安全審計、部署記錄查詢、部署頻率和失敗率分析等等)。基于Jenkins直接部署當然也可以獲取這些數據，但是把它做在獨立的部署系統內會更靈活和方便。

　　6.讓部署操作服務化

　　如之前提到，部署不僅僅開發和測試人員需要，要努力讓部署服務化，從而讓團隊內任何一個人都可以隨時觸發一次部署。Jenkins的操作界面對于開發或者測試人員可能還比較方便，但是對于其他人員來說則過于復雜(而且對于部署操作也不友好)。獨立部署系統可以在這方面做得更好，幫助更多的人低門檻完成部署操作。

　　當然，除了上面列出的這些原因外，獨立部署系統還有其他一些優勢(如方便部署版本管理等)，這里就不一一列舉。通過如上分析，我希望大家對于一個獨立部署系統的優勢以及它需要包含的內容能有一個整體理解。

　　當然，你可能會說“我正在按照上面的這些要求、基于Jenkins做自己的部署流程”。如果真是這樣，那恭喜你！其實你已經走在構建一個獨立部署系統的路上，而它和Jenkins的關系其實已經不大，或許你還可以考慮把這套系統對接其他構建系統(如CruiseControl、TeamCity等)。

　　寫在最后

　　如前所述，一個獨立的部署系統需要包括的內容是非常豐富的(絕對不僅僅是Jenkins部署插件要做的那些事情)。如下圖所示，部署系統需要連接項目中涉及的人、環境、制品庫以及構建環境等，只不過這種連接的目的是打通從制品到最終服務的整個流程(即本文之前持續交付流程中的第二及第三階段)。