自動化部署主要是為了解決專案多、環境多、持續集成慢、部署操作麻煩、手動操作易出錯、自動化運維等問題，
Jenkins是開源CI&CD軟體領導者， 提供超過1000個插件來支持構建、部署、自動化， 滿足任何專案的需要，
目標
l 支持多分支、多環境、多專案、多套組態檔、多編程語言
l 支持一鍵構建、集群發布
l 支持一鍵回滾歷史版本
l 快捷配置添加新的部署專案
l 支持多個專案使用同一個job發布或回滾
另外：也可以根據需要加入gitlab自動觸發構建、自動化測驗、釘釘通知、郵箱通知等需求
本實踐使用到的技術，可參考：《[CI&CD]jenkins自動化工具使用教程》
技術關鍵詞：jenkins master-slave，jenkins 插件（multijob、EnvInject），rsync工具，powershell，dotnet core cli，icacls工具等等
拷貝檔案權限解決方案：方案一：使用 icacls 工具賦權， 方案二：指定 jenkins服務 的運行賬戶
目錄
最終效果圖
目錄設計
約定及規范
架構設計
#、CICD架構圖
#、專案映射組態檔設計
#、一鍵發布job設計
#、一鍵回滾job設計
#、簡易多環境CICD流程
最終效果圖
一鍵發布
一鍵回滾
目錄設計
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檔案夾>>發布到部署目錄
為了更好的實作和控制”一鍵發布”這些階段，設計了如下輸入引數：
|
引數名 |
型別 |
默認值 |
說明 |
|
p_publish_model |
下拉單選 |
reality |
取值：reality、drill 發布模式 drill：演練，發布到應用服務器temp檔案夾后結束 |
|
p_app_key |
下拉單選 |
|
通過這個key到組態檔里面找站點的具體配置資訊 |
|
p_do_code_pull |
Bool |
True |
拉取最新代碼 |
|
p_do_build_package |
Bool |
True |
是否重新編譯打包 |
|
p_do_backup |
Bool |
True |
是否執行備份 |
|
p_publish_content |
多選 |
|
取值：app-file、config 發布檔案串列（多選）
app-file：應用檔案（不包含config檔案） config：組態檔 |
|
p_restart_daemon_process |
Bool |
True |
是否重啟守護行程（如果是IIS，勾選則重啟應用程式池，不勾選則回收應用程式池） 為避免檔案被占用，發布失敗，所以這里默認勾選，如果只是新增頁面檔案，可以不勾選 |
|
p_remark |
String |
|
備注資訊 |
#、一鍵回滾job設計
實作思路：在”一鍵發布”時，將發布記錄存到檔案中，存盤key為：p_app_key#2019-1219-1503，執行回滾時，選擇要回滾的歷史專案，先決議出p_app_key再獲取專案配置資訊，再回滾此專案的特定歷史版本，順序：決議專案資訊>>回滾到Temp檔案夾>>回滾到部署目錄，
設計的輸入引數如圖：
|
引數名 |
型別 |
默認值 |
說明 |
|
p_history_item |
下拉單選 |
|
每一次”一鍵發布”成功，都會生成一個對應的歷史記錄 |
|
p_restart_daemon_process |
Bool |
True |
是否重啟守護行程（如果是IIS，勾選則重啟應用程式池，不勾選則回收應用程式池） 為避免檔案被占用，回滾失敗，所以這里默認勾選， |
|
p_remark |
String |
|
備注資訊 |
#、簡易多環境CICD流程
一般軟體公司對于軟體的開發、測驗、發布都有好幾個環境，所以針對各個環境都會有對應的CICD流程，這邊設計了一個簡易的多環境CICD流程圖，如下： （在線畫圖工具：processon.com）
自動觸發CICD還是手動觸發CICD？？？我認為：
開發環境采用手動觸發：因為對于開發環境，提交代碼比較頻繁，而且有時候提交到git也并不想觸發CICD，可以采取每晚定時自動觸發CICD，便于例外代碼及時拋出
測驗環境采用自動觸發：因為測驗代碼的 git 分支合并是有條件限制的，合并頻率比較少
生產環境采用手動觸發：因為生產環境的發布比較復雜，合并分支后是不能直接自動觸發CICD的，比如有嚴控發布時間、負載隔離（藍綠部署）等要求，所以手動觸發控制力強
over，謝謝查閱，覺得文章對你有識訓，請多幫推薦，歡迎向我提供更好的資料資訊，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/29231.html
標籤：架構設計
上一篇：分庫分表之第三篇
下一篇：如何設計出優美的Web API？