作者介紹

[[162538]] 

　　徐桂林，當(dāng)前在FIT2CLOUD負(fù)責(zé)公司的技術(shù)布道和生態(tài)合作。在此之前先后供職于意法半導(dǎo)體、Autodesk和阿里云。徐桂林熱衷于云計算(尤其是公有云IaaS平臺)，有過多年AWS的生產(chǎn)環(huán)境工作經(jīng)歷，是較早在國內(nèi)分享AWS上實踐經(jīng)驗的作者之一。

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

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

　　持續(xù)交付與部署系統(tǒng)

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

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

　　1.從代碼(Code)到制品庫(Artifact)：這個階段主要對開發(fā)人員的代碼做持續(xù)構(gòu)建并把構(gòu)建產(chǎn)生的制品集中管理，是為部署系統(tǒng)準(zhǔn)備輸入內(nèi)容的階段。

　　2.從制品到可運行服務(wù)：這個階段主要完成制品部署到指定環(huán)境，是部署系統(tǒng)的最基本工作內(nèi)容。

　　3.從開發(fā)環(huán)境到最終生產(chǎn)環(huán)境：這個階段主要完成一次變更在不同環(huán)境的遷移，是部署系統(tǒng)上線最終服務(wù)的核心能力。

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

　　持續(xù)交付對部署系統(tǒng)的要求

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

　　1.解耦構(gòu)建和部署過程

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

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

　　有了統(tǒng)一制品庫后，構(gòu)建過程自動提交產(chǎn)生的制品到此，而部署過程則主動到制品庫拉取需要的制品進(jìn)行部署，從而實現(xiàn)構(gòu)建和部署的完整解耦。

　　2.管理復(fù)雜的部署環(huán)境

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

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

　　由部署系統(tǒng)負(fù)責(zé)把部署請求分發(fā)到指定環(huán)境內(nèi)的每臺主機并自動執(zhí)行。如果基于Jenkins來直接部署，則必然把環(huán)境管理的很多復(fù)雜度引入到部署流程內(nèi)部。

　　3.支持多種部署策略

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

　　4.落實部署流程規(guī)范

　　在一個公司內(nèi)部經(jīng)常有不同的項目，使用不同的編程語言，而部署流程也五花八門。從控制風(fēng)險，減少重復(fù)操作，降低部署自動化難度等多重考量，公司都傾向制定一套標(biāo)準(zhǔn)的部署流程。

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

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

　　5.獲取部署運營數(shù)據(jù)

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

　　6.讓部署操作服務(wù)化

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

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

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

　　寫在最后

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