自動化部署主要是為了解決項目多、環境多、持續集成慢、部署操作麻煩、手動操作易出錯、自動化運維等問題。
Jenkins是開源CI&CD軟件領導者, 提供超過1000個插件來支持構建、部署、自動化, 滿足任何項目的需要。
目標:
- 支持多分支、多環境、多項目、多套配置文件、多編程語言
- 支持一鍵構建、集群發佈
- 支持一鍵回滾歷史版本
- 快捷配置添加新的部署項目
- 支持多個項目使用同一個job發佈或回滾
另外:也可以根據需要加入gitlab自動觸發構建、自動化測試、釘釘通知、郵箱通知等需求
最終效果圖
一鍵發佈
一鍵回滾
Jenkins相關目錄設計
<code>----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
……/<code>
約定及規範
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 分支合併是有條件限制的,合併頻率比較少。
- 生產環境採用手動觸發:因為生產環境的發佈,有嚴控發佈時間的,手動觸發控制力強。
閱讀更多 程序員小楊 的文章