Jenkins是被廣泛應(yīng)用的持續(xù)集成、自動化測試、持續(xù)部署的框架，甚至有些項目組順便將其用來做流程管理的工具。根據(jù)任務(wù)的多寡，Jenkins通常有兩種典型的部署方式。

　　單節(jié)點（Master）部署

　　這種部署適用于大多數(shù)項目，其構(gòu)建任務(wù)較輕，數(shù)量較少，單個節(jié)點就足以滿足日常開發(fā)所需。

　　多節(jié)點（Master-Slave）部署

　　通常規(guī)模較大，代碼提交頻繁（意味著構(gòu)建頻繁），自動化測試壓力較大的項目都會采取這種部署結(jié)構(gòu)。在這種部署結(jié)構(gòu)下，Master通常只充當(dāng)管理者的角色，負(fù)責(zé)任務(wù)的調(diào)度，slave節(jié)點的管理，任務(wù)狀態(tài)的收集等工作，而具體的構(gòu)建任務(wù)則會分配給slave節(jié)點。一個Master節(jié)點理論上可以管理的slave節(jié)點數(shù)是沒有上限的，但通常隨著數(shù)量的增加，其性能以及穩(wěn)定性就會有不同程度的下降，具體的影響則因Master硬件性能的高低而不同。

　　關(guān)于Docker

　　Docker是一款針對程序開發(fā)人員和系統(tǒng)管理員來開發(fā)、部署、運行應(yīng)用的一款虛擬化平臺。Docker 可以讓你像使用集裝箱一樣快速的組合成應(yīng)用，并且可以像運輸標(biāo)準(zhǔn)集裝箱一樣，盡可能的屏蔽代碼層面的差異。Docker 會盡可能的縮短從代碼測試到產(chǎn)品部署的時間。簡單來說Docker提供了一種技術(shù)，可以讓開發(fā)人員方便地將應(yīng)用代碼已經(jīng)運行時的環(huán)境一并打包到一個鏡像中，然后將這個鏡像上傳至鏡像倉庫。在測試或者產(chǎn)品環(huán)境只需要下載這個鏡像然后將其啟動就完成了部署（就好比打開一個集裝箱那么簡單）。關(guān)于Docker更詳細的內(nèi)容請參考官網(wǎng)文檔。

　　當(dāng)前Jenkins遇到的困難

　　隨著敏捷開發(fā)的普及，自動化測試成為每個項目的必須。一個經(jīng)過多年開發(fā)的項目，其累積的自動化測試數(shù)量是驚人的。為了保證每次的部署都是正確的，就需要每次回歸所有的自動化測試用例。根據(jù)項目的不同，有些需要每周跑一輪回歸測試，而有些項目則需要每天一輪。所以我們會把所有的測試用例進行分組，同時在多臺測試機上運行，以減少一輪測試所需要的時間。而這就要求我們有足夠多的硬件資源來滿足這需求。下圖展示了一個典型的通過Jenkins來管理自動化測試的拓補結(jié)構(gòu)。一臺Master主機管理多臺測試機，Master將測試任務(wù)分配給測試機。

　　當(dāng)前Jenkins（Master-Slave）結(jié)構(gòu)當(dāng)前Jenkins（Master-Slave）結(jié)構(gòu)

　　這種結(jié)構(gòu)存在一些缺陷：

　　自動化的測試通常都是通過捕捉屏幕控件來模擬用戶的行為以達到測試的目的，這就意味著一臺測試機上只能同時運行一組測試用例，否則用例之間就會相互干擾。這就存在資源浪費，因為測試機的配置往往可以支持多組測試用例。

　　維護人員得確保測試機都保持在線，當(dāng)測試機器數(shù)量較多的時候，比如100臺甚至1000臺的時候，這維護的壓力就比較大。

　　通常回歸測試是在晚上運行（如此就能在開發(fā)組第二天上班時發(fā)現(xiàn)前一天提交的代碼是否正確），但這上百臺測試機不論白天晚上都在工作狀態(tài)，這是另一維度的浪費。

　　很重要的一點，測試機器會因為各種原因?qū)е聹y試環(huán)境被污染，導(dǎo)致測試不能順利進行，而此時除了維護人員手工處理外，沒有特別好的方案。

　　之前我們提到過，當(dāng)slave數(shù)量達到一定程度的時候，作為Master的節(jié)點就會出現(xiàn)性能變差，穩(wěn)定性下降。

　　每個Slave節(jié)點在開始跑測試之前都需要從中央庫下載最新的分發(fā)包，解壓，設(shè)定運行環(huán)境。這個過程通常也占用不少時間，想象一下，突然間上百個slave開始下載最新的庫，這對中央庫是一個極大的沖擊。