一文教你使用 Jenkins 設計多環境、多項目持續集成環境！

滴答的雨
https://www.cnblogs.com/heyuq...

自動化部署主要是爲了解決項目多、環境多、持續集成慢、部署操做麻煩、手動操做易出錯、自動化運維等問題。

Jenkins是開源CI&CD軟件領導者， 提供超過1000個插件來支持構建、部署、自動化， 知足任何項目的須要。

目標：

• 支持多分支、多環境、多項目、多套配置文件、多編程語言
• 支持一鍵構建、集羣發佈
• 支持一鍵回滾歷史版本
• 快捷配置添加新的部署項目
• 支持多個項目使用同一個job發佈或回滾

另外：也能夠根據須要加入gitlab自動觸發構建、自動化測試、釘釘通知、郵箱通知等需求

最終效果圖

一鍵發佈

一鍵回滾

Jenkins相關目錄設計

----jenkins-ex      jenkins構建時使用到的目錄
------software      Jenkins安裝目錄
--------master
--------slave
------backup        jenkins備份目錄
--------master
------module        功能模塊，每一類功能相關的文件放在對應的子文件夾中
--------common
----------script        各模塊公用的腳本
------publish       發佈功能
--------settings
----------config    構建時配置文件。Eg: jenkins_profile.pubxml、項目配置文件等
------------test-publish-template-app-config.json   項目映射配置表
----------script    Jenkins job構件時調用的腳本（方法封裝）
------source-code   拉取的源代碼存放目錄
--------test
----------系統標識 
------------應用名
------build-result      構建產物（編譯後的結果）
--------test
----------系統標識 
----------應用名
------temp-file 臨時文件，job執行過程當中產生的文件
--------builder-history 構建歷史記錄文件
--------job-params      構建過程當中傳遞參數的文件
------app-config  應用對應的環境配置文件
--------test
----------系統標識
------------應用名
------other-sub-module
……

約定及規範

jenkins job命名

• job名全小寫，多單詞用」-」分割。（eg：publish-template-onekey-deploy）
• job命名約定：模塊名-環境-功能名。（eg：publish模塊，publish-test-onekey-deploy）
• 模塊中組件job命名約定：模塊-c-組件名。（eg：publish-c-pull-code）
• job輸入參數以」p_」爲前綴

Jenkins job中的腳本命名（eg：powershell）

• 變量全小寫，多單詞用」_」分割

規範約定

• 表明路徑的變量值，以」」結尾
• 備份名字中用「#」作分隔符，還原時好取參數（eg：p_app_key#2019-1219-1503）

架構設計

CICD架構圖

CICD過程主要在兩個局域網中執行：構建服務器(開發內網)和部署服務器(生產內網)

項目映射配置文件設計

想要實現使用一個job，經過下拉來」 發佈|回滾」不一樣的項目，咱們須要一個靈活的項目配置映射文件，相似以下：

配置文件選項含義從命名上能夠識別，主要包括：環境、代碼分支、部署路徑、拷貝排除文件列表、項目信息（項目惟一標識、目錄文件夾名、源代碼路徑、開發語言、集羣節點信息…）等等

• app_config節點下的配置，能夠覆蓋父節點配置，適配項目特定的部署要求。
• app_config是數組節點，能夠輕鬆添加新的部署項目，實現新項目的快速CICD。

一鍵發佈job設計

「一鍵發佈」主要經歷的階段有：組合項目相關參數>>獲取最新代碼>>編譯打包>>推送應用文件到服務器>>應用備份>>拷貝到Temp文件夾>>發佈到部署目錄

爲了更好的實現和控制」一鍵發佈」這些階段，設計了以下輸入參數：

一鍵回滾job設計

實現思路：在」一鍵發佈」時，將發佈記錄存到文件中，存儲key爲：p_app_key#2019-1219-1503。執行回滾時，選擇要回滾的歷史項目，先解析出p_app_key再獲取項目配置信息，再回滾此項目的特定歷史版本。

設計的輸入參數如圖：

簡易多環境CICD流程

通常軟件公司對於軟件的開發、測試、發佈都有好幾個環境，因此針對各個環境都會有對應的CICD流程，這邊設計了一個簡易的多環境CICD流程圖，以下：

自動觸發CICD仍是手動觸發CICD？？？，我認爲：

• 開發環境採用手動觸發：由於對於開發環境，提交代碼比較頻繁，並且有時候提交到git也並不想觸發CICD。能夠採起每晚定時自動觸發CICD，便於異常代碼及時拋出
• 測試環境採用自動觸發：由於測試代碼的 git 分支合併是有條件限制的，合併頻率比較少
• 生產環境採用手動觸發：由於生產環境的發佈，有嚴控發佈時間的，手動觸發控制力強

關注公衆號《架構文摘》，天天一篇架構領域重磅好文，涉及一線互聯網公司應用架構（高可用、高性能、高穩定）、大數據、機器學習、Java架構等各個熱門領域。