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

　　單節點（Master）部署

　　這種部署適用于大多數項目，其構建任務較輕，數量較少，單個節點就足以滿足日常開發所需。

　　多節點（Master-Slave）部署

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

　　關于Docker

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

　　當前Jenkins遇到的困難

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

　　當前Jenkins（Master-Slave）結構當前Jenkins（Master-Slave）結構

　　這種結構存在一些缺陷：

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

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

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

　　很重要的一點，測試機器會因為各種原因導致測試環境被污染，導致測試不能順利進行，而此時除了維護人員手工處理外，沒有特別好的方案。

　　之前我們提到過，當slave數量達到一定程度的時候，作為Master的節點就會出現性能變差，穩定性下降。

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