電商測試環境Jenkins multibranch pipeline實踐

1、背景狀況

1. 整個項目組有32個java應用，10個javascript應用以及若干其餘應用，而且還有增長的趨勢；
2. 3套測試環境，測試發佈很是頻繁，而且有同一個應用不一樣分支並行測試的狀況；
3. 版本管理器gitlab在公司內網局域網，測試環境在公網的青雲主機上；
4. Java應用在測試環境，可能有單節點或多節點部署；
5. Java應用很是多，內存吃緊，須要合理部署應用在主機上，而且增長限制內存使用的啓動參數；
6. Java應用有多種部署及啓動方式，有tomcat部署的，有一個整的jar包方式部署的，有jar包與配置文件分離而且主要配置都在配置管理中心的部署方式；
7. 代碼管理分支策略方式爲，從master分支切出功能開發分支，而且其餘分支提交到master分支的變動及時合併到此開發分支用以消除代碼衝突，此分支發佈生產環境以後，合併到master分支；
8. 配置文件繁多，不一樣的環境配置文件不一樣；

2、multibranch pipeline介紹及實現構想
一、簡單介紹：
A、先介紹下什麼是Jenkins 2.0，Jenkins 2.0的精髓是 Pipeline as Code，是幫助Jenkins實現CI到CD轉變的重要角色。什麼是Pipeline，簡單來講，就是一套運行於Jenkins上的工做流框架，將本來獨立運行於單個或者多個節點的任務鏈接起來，實現單個任務難以完成的複雜發佈流程。Pipeline的實現方式是一套Groovy DSL，任何發佈流程均可以表述爲一段Groovy腳本，而且Jenkins支持從代碼庫直接讀取腳本，從而實現了Pipeline as Code的理念。
B、multiBranch Pipeline的使用首先須要在每一個分支代碼的根目錄下存放Jenkinsfile（Pipeline的定義文件），咱們能夠理解下maven的pom.xml文件，Jenkinsfile做爲pipeline的管理文件也須要在源代碼中進行直接的配置管理。這就要求devops工程師（QA、運維等）首先要有代碼庫的權限，或者至少賦能給dev工程師jenkinsfile的設計能力。
二、Groovy DSL定義了測試環境發佈的全部步驟，包括：合併master分支，選擇配置文件與替換，編譯構建，上傳構建後的應用包文件，部署應用；
三、上傳包文件有惟一的shell腳本，不一樣測試環境的不一樣應用的包對應上傳到包文件中轉主機上不一樣的路徑;
四、部署應用，都使用ansible的playbook劇本控制，java應用包括結束進程，替換應用包，重啓應用。靜態頁面只須要替換。因爲各個應用的部署方式差異較大，全部暫時每一個應用都有單獨ansible劇本，部署到不一樣環境參數有不一樣變量；
五、Groovy DSL流程固定，將其中變量做爲參數列出來，再增長新的應用須要發佈的時候，直接用模板，只須要修改變量參數便可使用；
六、Jenkinsfile保存在gitlab中項目代碼的master分支根目錄，不會丟失，不會被篡改，對Jenkins服務器依賴小不須要額外備份；
七、每一個應用只須要配置一個Jenkins的項目便可部署到多個環境，其中實現選擇功能，使用"Extended Choice Parameter"插件；
八、發佈不一樣的分支直接選擇便可；
九、每套環境有多臺主機，ansible的劇本根據各個主機上是否有次應用的目錄來肯定是否將應用部署到主機上，不須要配置的時候指定主機；
十、使用cksum進行CRC校驗；
十一、打印出部署的java應用的進程ID。 
3、總體拓撲結構

1. Jenkins、nexus和gitlab都在公司內網局域網，測試環境都是青雲雲主機；
2. 測試環境由一臺專門的中轉主機（transfer station），打包以後的包文件先上傳到這個中轉主機上，而後再分發到對應的測試環境的主機；
3. 測試環境的主機，啓動java應用進程，結束java應用進程，刪除舊的包，傳輸新的包，所有是Jenkins的主機經過ansible控制；
4. Multibranch pipeline方式，gitlab上項目的master分支，增長Jenkinsfile文件。
5. 經過Jenkins的pipeline流水線做業，完成了從編譯構建到部署的所有過程，即持續部署（continue deploy）。
6. 爲了簡化過程，gitlab用戶名密碼保存在Jenkins主機的linux系統上，Jenkins主機ansible也是給測試環境主機分組而且用ssh密鑰登陸。
7. 總結：Jenkinsfile文件放在gitlab項目master分支的根目錄；Jenkins系統上配置multibranch pipeline項目；上傳文件的shell腳本和部署應用的ansible playbook腳本都存放在Jenkins的主機上，Jenkinsfile中定義了調用這兩個腳本。

4、發佈過程涉及到的步驟
一、合併master分支代碼；
二、替換不一樣環境的配置文件；
三、編譯構建;
四、上傳編譯的包文件到linux主機；
五、結束應用的舊進程，替換包文件，重啓應用。

5、Groovy DSL實現

一、Jenkins pipeline的代碼實現，先將全部的變量都單獨抽取出來，使用腳本編程方式。由於有合併master分支到測試分支的須要，因此得獲取到Jenkins項目的環境變量：gitlab URL和分支名字；選擇環境的變量使用"Extended Choice Parameter"插件；

二、合併master分支而且提交

三、替換配置文件，這裏須要判斷提供的路徑指向的是目錄仍是文件

四、maven構建

五、上傳構建完成後生產的包，調用shell腳本，其中包的相對路徑、Jenkins的job名字和部署到的環境爲三個參數變量

六、部署，須要三個參數，分佈是Jenkins的job名字，部署到的環境，以及部署此java應用的ansible playbook劇本的絕對路徑，由於劇本保存在Jenkins的主機上。

6、上傳腳本

Shell腳本作了三件事：

1. 根據Jenkinsfile調用腳本的時候給的包路徑的參數，判斷是否須要歸檔打包，若是須要打包則tar歸檔打包；
2. Cksum在Jenkins主機上進行CRC校驗；
3. 上傳包到中轉主機的指定的路徑，此處用scp經過公網上傳。

 

7、ansible部署劇本

一、判讀是否存在此應用的路徑，記錄結果，忽略報錯

二、kill此應用的進程，若是步驟1的判斷結果result是succeeded的時候

三、刪掉舊的包文件，因爲此處部署測試環境，無需備份保留，能夠直接刪除，條件也是步驟1的判斷結果result是succeeded

四、從包中起色器下載包文件，條件也是步驟1的判斷結果result是succeeded

五、cksum進行CRC校驗

六、從新啓動應用，捕獲報錯信息

七、返回進程ID

 
注意：
上傳包的shell腳本和部署應用的ansible劇本中，不少命名都是統一了方式。

8、Jenkins配置job

一、新建multibranch pipeline項目

二、配置gitlab地址

三、構建配置

四、配置完畢以後保存，而後掃描分支

五、掃描出來分支，點進去，構建，這裏會顯示全部的變量

六、在控制檯的輸出中，能看到CRC校驗值以及進程ID