自動化部署主要是為了解決項目多、環境多、持續集成慢、部署操作麻煩、手動操作易出錯、自動化運維等問題。
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服務 的運行賬戶
目錄
最終效果圖
一鍵發布
一鍵回滾
目錄設計
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 應用對應的環境配置文件（eg：web.config，appsetting.json） ----------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，謝謝查閱，覺得文章對你有收獲，請多幫推薦。歡迎向我提供更好的資料信息。