Jenkins系統+獨立部署系統

原文出自：http://os.51cto.com/art/201601/504846.htm

有了Jenkins，爲何還須要一個獨立的部署系統？

如今已經有Jenkins，它自身提供了豐富的部署插件(如WebSphere部署插件、Tomcat部署插件等)，方便用戶直接把構建出來的部署包自動化部署到指定機器(甚至雲服務)。那爲何不能夠圍繞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部署插件要作的那些事情)。以下圖所示，部署系統須要鏈接項目中涉及的人、環境、製品庫以及構建環境等，只不過這種鏈接的目的是打通從製品到最終服務的整個流程(即本文以前持續交付流程中的第二及第三階段)。