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