Jenkins除了開源和免費，還有一個最吸引人的功能之一就是支持插件。
Jenkins不光有豐富的第三方插件，還可以自己動手編寫插件，和其他工具進行深度的集成，從而達到符合公司產品管理需求的一個定制化。
接下來我們會分享一系列關於Jenkins插件的使用和開發實踐經驗，介紹一些經典而又實用的第三方插件和公司內部自己開發的插件，希望大家能在工作中根據項目的需求靈活地運用。
這次首先介紹的5個插件都是和Jenkins的job相關的，通過這些插件，可以按需連接各個job，使之協同工作。
那開始介紹前，讓我們來看看為什么需要這些插件來連接各個job呢。有人可能會說，為什么不能把產品的持續集成步驟統統建立在一個job上呢？
- 首先，Jenkins有一個限制，就是一個job的一次構建的所有任務只能運行在一個節點上，那如果產品的編譯/部署/測試需要在不同平台下（如編譯必須在Linux下，而執行用例需要在Windows下）就必須建立不同的job
- 再次，如果只有一個job必然構建時間會變長，也就是意味着產品的質量反饋變慢（必須等到所有的任務才做完才能得到反饋）
- 還有，分開建job也是為了相互之間的“弱耦合”，之后相應job的配置改動能盡量小的影響到其他job
- 最后，這樣可以使產品的持續集成流程更加清晰，及時發現產品相應的短板
功能介紹：這是個比較簡單的插件，只是簡單地把某個job的構建物拷貝到當前job的工作區。
簡單配置：
實踐應用：
- 在產品被編譯/打包之后，需要在測試/聯調/演練多個環境下部署的時候，可以采用。
一個job負責代碼的編譯和打包，並把構建物（通常是WAR，JAR，TAR等）存檔下來，
然后之后的多個job可以分別獲取相應的構建物用於產品的部署，保證了部署環境的一致性。
Tips：
+ 一定要保證上游job的構建物是被存檔的
+ 默認情況下，拷貝過來的構建物會以相同的目錄結構存儲，如果只想保留文件而已，可以選擇“Flatten directories”，這樣所有的構建物都會直接拷貝到“Target directory”，而不會保留目錄結構
功能介紹：這是一個擴展型的插件，使各個job連接的時候可以傳遞一些job相關的信息
- 當前job的參數
- 自定義的參數
- SCM相關信息
- 運行的Node信息
簡單配置：
實踐應用：
- 傳遞SVN Revision： 在代碼檢出階段會獲取相應的SVN Revision信息，傳遞這個信息到下游的job中，
在下游的各個job中直接檢出相對應版本的代碼，保持各個構建的版本一致性，防止由於頻繁的代碼提交導致各個job運行版本的不一致
- 保持各個job運行在同一個節點下： 如果有多套測試環境，可以通過這個勾選這個選項保持構建環境的一致性
Tips：
+ 傳遞SVN Revision或是GIT Revision可以通過如下設置來完成
+ 如果不需要傳遞任何參數，一定要記得勾選“Trigger build without parameters”
功能介紹：這是一個用於生成特定視圖的插件，可以把job之間的關聯關系可視化，使產品的流程也隨之可視化。
簡單配置：
實踐應用：
- 在配置產品的持續集成時，往往會有多個job協同工作，比如編譯/打包，靜態代碼檢查，單元測試，接口測試，UI測試，性能/壓力測試，
而各個產品又相互有一定的依賴。通過在這個插件中設置初始job，就能很直觀地把job之間的關系整理出來，也能看到產品每次構建的全局情況。
在后期還可以從構建信息中挑選合適的版本，增加發布環節。
Tips：
+ 通過設置選項“Show pipeline parameters in revision box”可以直觀地顯示job的build number，結合
VersionNumberPlugin就可以顯示SVN revision
+
通過設置選項“Show pipeline parameters in project headers”可以直觀地顯示job的某些參數，如測試環境
功能介紹：這是一個集成了ParameterizedTrigger和BuildPipeline的插件，但它是形成一個新的job，而不是一個視圖。
並且它不要求job之間本身就存在依賴關系。
這樣一來，建立job的時候可以保持相對的獨立性，而通過這個插件來組裝成產品所需要的持續集成環境。
簡單配置：
實踐應用：
- 如果需要建立多條pipeline，並且在各條pipeline中有些job其實是可以共用的時候，可以考慮使用這個插件。例如產品有兩個分支develop和release， 需要分別檢出代碼（A1，A2），編譯（B），單元測試（C），對於develop分支只需進行簡單的回歸測試（D），而對release分支不僅僅是回歸測試（D)，還必須有性能測試（E)。這種情況下，就會有A1-B-C-D和A2-B-C-D-E兩條pipeline，對於D來說，下游job是不確定的，這時
就可以通過建立兩個Multijob來實現（當然，也可以通過PrameterizedTrigger通過設置和讀取變量來實現，但是配置較為復雜）
Tips：
+ 在創建job時一定要選擇“MultiJob Project”，在“free-style project”下默認是不能選擇使用這個插件的
+ 對於某些job的結果不想影響下游job的執行，例如靜態代碼檢查，可以通過以下設置來達到目的
5.
Join Plugin
功能介紹：這也是一個觸發job的插件，亮點在於它觸發job的條件是等待所有當前job的下游的job都完成才會發生。
當然，只有在當前job有兩個及以上的下游job時才有意義。
簡單舉個例子來說，A同時觸發B1和B2兩個job，然后配置這個插件又觸發C，這時C就會等B1和B2都完成之 后才會被執行
簡單配置：
實踐應用：
- 有些產品的部署會依賴於某些第三方的產品，可以同時部署自身的產品和第三方服務，這時接下來的測試工作就需要等待所有這些部署都完成，自然這個插件就能有用武之地
-
為了加快構建的速度，通常可以設置單元測試和冒煙測試同時進行，而隨后的功能測試又希望是在單元測試和冒煙測試都通過的情況下才進行，這種情況下Join插件就是必須的了
Tips：
+ 默認情況下，通過Join插件觸發的job是不能傳遞參數的，如果有需要，可以勾選“Trigger parameterized build on other project”，這樣其實就是把Join插件和ParameterizedTrigger插件集成起來了
小結：上面介紹的這些插件一般情況下不會都使用到，並且某些功能不止一個插件可以實現，所以大家可以根據產品和項目的需求來靈活應用，搭建出可靠、可維護、可視化強的持續集成環境