jenkins+gitlab自動化編譯部署方案探索及服務端編譯webpack實戰
一. 背景
之前我們的開發流程為在本地進行webpack打包編譯，然後svn提交源代碼和編譯後的代碼。同時每次提交前也會從svn更新源代碼和編譯後的代碼。這樣做有幾個缺點：
1. svn 更新和提交編譯後的代碼造成大量沖突文件
2. 由於我們使用非覆蓋式發布的命名方式，在經過小組多人多次優化提交測試之後，在整理需要發布的文件列表時，很容易遺漏一些文件
3. 在涉及到多人開發同一功能時容易產生代碼被覆蓋、人工安排發布優先級、手動註釋他人未上線代碼等情況
4. svn的分支開發繁瑣不友好，加重工作量
最不能容忍的是第一第二點，於是我們改成服務端打包編碼，本地只提交和更新源代碼，這樣就會大大減少沖突。同時，利用jenkins自動把服務端打包編譯後的代碼部署到測試和線上環境，省去了手動整理待發布文件列表的麻煩，也避免了發布文件遺漏的情況。為了提高開發流程質量，科學友好的規範開發流程，我們選擇gitlab作為新的代碼倉庫，通過分支管理和代碼review來提高開發效率，減少發布錯誤。
二. 自動化部署架構
完成功能：
1. 代碼倉庫用gitlab托管，使用AoneFlow分支管理模式（阿裏命名的一種分支管理模式，借鑒於gitflow, githubflow和gitlabflow）。
2. 源代碼合並到測試分支後，jenkins自動打包編譯並將編譯後的代碼部署到測試環境。
3. 源代碼合並到發布分支後，jenkins自動打包編譯並將編譯後的代碼部署到線上環境。
4. 給Master穩定分支打版本tag，同時增加tag版本說明。
5. 腳手架和代碼分離，保留一個腳手架倉庫，提供給各個環境編譯。
部署方案探索
A. jenkins合並代碼並編譯，ssh發送編譯後代碼到測試環境
缺點：發送代碼量大，耗時嚴重
B. jenkins合並代碼並編譯，編譯結果提交到gitlab，ssh連接測試環境從gitlab更新代碼
缺點：編譯後代碼合並到gitlab沖突多，麻煩
C. jenkins合並代碼，ssh連接測試環境更新gitlab代碼，然後運行編譯命令
優點：速度快，沖突少
綜上，我們選擇方案C進行部署代碼。
發布到線上，不能通過merge到release/prop發布分支後自動觸發jenkins構建，因為我可能同時有多個feature分支需要一次性發布到線上，這個時候需要多個feature分支挨個合並到發布分支，然後才能執行構建操作。所以合並到發布分支和構建部署到線上應該分為兩個獨立部分，分別執行。
一圖勝千言，結合我司的實際開發環境，目前整體架構如下：
三. jenkins 配置實戰
關於jenkins安裝的方案網上有很多，可以另行查詢。
1. 首先安裝插件：
- Gitlab Hook Plugin
- GitLab Plugin
- Publish Over SSH
系統管理--管理插件--可選插件
2. 新建job
3. 配置git源碼
點擊新建的job，點擊配置--源碼管理
Repository URL ： 填寫git倉庫地址
點擊add--jenkins
選擇 ssh username with private key (需要提前在jenkins服務器生成ssh keys)
- username: root
- enter directly: 私鑰內容 或者 From a file on Jenkins master ： 私鑰的存放路徑比如/home/role/.ssh/id_rsa
- passphrase: 生成ssh keys時填的密碼，如果當時沒設置則不填
如果選擇私鑰內容，那就需要在gitlab上把你的公鑰填到gitlab ssh keys:
點擊Credentials選擇剛添加的證書，如果此時沒有紅字報錯，證明設置成功！
4. 設置webhook
webhook按我的理解就是可以觸發的一個接口，可以用它來在一定條件下觸發某個任務。
在job配置中找到如下選項：如果沒有，則先安裝Gitlab Hook Plugin
復制紅框中的webhook url， 打開gitlab如下圖在URL處填寫webhook地址
add後點擊test，如果提示
則設置成功，jenkins成功觸發！
！！！註意：
gitlab的webhooks url 是根據jenkins構建權限連接設置的，如果必須登錄才能構建就必須獲取jenkins的用戶名及token，可以在jenkins用戶-設置裏面查看到 ，url格式
http://<username>:<api-token>@<jenkins-server>/
如果不須登錄就能構建就直接設置為 http//jenkins-server/job/security_Usm/build?delay=0sec ，security_Usm是job名稱
所以，如果你出現如下錯誤提示：
Hook executed successfully but returned HTTP 403 <!doctype html><html lang="en"><head><title>HTTP Status 403 – Forbidden</title><style type="text/css">h1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} h2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} h3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} body {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} b {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} p {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;} a {color:black;} a.name {color:black;} .line {height:1px;background-color:#525D76;border:none;}</style></head><body><h1>HTTP Status 403 – Forbidden</h1><hr class="line" /><p><b>Type</b> Status Report</p><p><b>Message</b> anonymous is missing the Job/Build permission</p><p><b>Description</b> The server understood the request but refuses to authorize it.</p><hr class="line" /><h3>Apache Tomcat/8.5.24</h3></body></html>
需要更改你的gitlab中webhook地址為如下形式：
http://maoyu:[email protected]:8080/jenkins/project/front-end
5. ssh部署到服務器
全局配置ssh服務器：系統管理--系統設置
、
配置好後點擊Test，出現success即表示成功。
然後配置具體的發布內容：
- source files: jenkins中工作空間下的路徑
- remote directory: 是相對全局配置中Publish over SSH -- SSH server -- Remote Directory的路徑
source files亦可不填，直接連接服務器後執行exec command.
6. 顯示構建日誌的時間
如果想在console output中顯示如下的時間
配置如下即可：
7. 自動合並Gitlab Merge Request
如果你想在Merge request後使用jenkins自動合並代碼，可以使用下面的方法，如果不需要這樣，比如push到某個分支直接觸發webhook則可以跳過此步驟。
我的目前構建方案中，在發布到測試環境時，兩種都有，即既可以通過Merge Request觸發自動合並然後構建，也可以手動合並後產生push事件觸發webhook。但很可能之後會改成提交到對應分支後，自動觸發webhook，jenkins合並到相應分支然後編譯部署。看具體公司的使用習慣和一些規範吧。
使用插件：Gitlab Merge Request Builder
此插件是通過設定分支，定時檢查分支有沒有收到Merge Request請求來決定是否進行構建。gitlab是個審核管理 ，當jenkins構建完成之後，gitlab便會合並分支。配置如下：
如果想在gitlab pipeline成功之後自動執行merge操作，需要勾上下面的配置，可以說這是必須的，不然你就完不成自動合並：
gitlab對應的合並界面有如下變化：
初始界面如下，可以在右上角close 合並請求：
在建立合並請求到合並成功，可能會出現如下的紅叉提示Could not connect to the CI server. 不用管它，可以忽略。
如果合並失敗，界面提示如下，則需要去jenkins查看日誌具體為什麽合並失敗：
或者你可能會看到如下的提示：
合並成功如下，在discussion中會有jenkins自動添加的一些comment：
Gitlab Merge Request Builder會觸發gitlab的pipeline, 無需配置gitlab的CI/CD。
如果在gitlab 的merge requests部分，Discussion沒有Build Started，Build triggered, Build finished Test Passed.這些提示，說明Gitlab Merge Request Builder插件沒有起作用，仔細檢查配置Gitlab Project Path等是否正確，如果都正確可以嘗試重啟jenkins，重新發起merge request。
如果在配置構建觸發器下的 Gitlab Merge Request Builder，點擊apply時報如下錯誤，則在系統管理--系統配置中檢查Gitlab Merge Request Builder配置Jenkins Username和Jenkins API Token是否正確。
Gitlab merge沖突：
點擊 解決沖突 手動編輯解決沖突，保存即可重新觸發merge request，然後自動合並
8. 參數化構建
參數化構建即第一你需要手動點擊構建按鈕，第二你可以設置一些參數變量在構建中使用，比如開發環境，分支參數等。
為什麽需要參數化構建？我們目前項目比較簡單，其實無需參數化構建，但在部署到線上後給master打tag時，遇到點麻煩，即不能給tag設置一些個性化的說明文案，這樣找起tag單純看版本號可能很難知道某個版本裏面完成什麽功能。所以我們在發布到線上時，增加了deploymsg即要發布功能的描述，用來作為tag的描述信息。
參數化構建可以使用jenkins自帶的參數化構建過程，如下：
參加參數中選擇string parameter， 第一項名字即你要添加的變量名。
設置好後保存，即完成了參數化構建的設置。
第二種方法可以使用jenkins插件，jenkins有著幾千款各種功能插件，非常豐富，基本我們想要的功能都會有插件支持。
這裏我們使用的插件是：Generic Webhook Trigger
按照以上配置即配置了一個ref變量。
附1：如何從jenkins知道 gitlab webhook是哪個分支觸發的呢？
看下圖
更簡便的方法是gitlab plugin提供的變量：
可以再shell中打印如下查看：
echo "gitlabBranch: ${gitlabBranch}";
附2：同一服務器生成多個ssh key:
只需要對文件名命名不同的名字即可，如下：
附3：Jenkins定時語法：
如以下表示每2分鐘執行一次任務：
cron語法有五位，分別的意義是：
- MINUTES Minutes in one hour (0-59)
- HOURS Hours in one day (0-23)
- DAYMONTH Day in a month (1-31)
- MONTH Month in a year (1-12)
- DAYWEEK Day of the week (0-7) where 0 and 7 are sunday
其中每個字段除了可以使用取值範圍內的值外，還能使用一些特殊的字符。
- * 匹配範圍內所有值
- M-N 匹配M~N範圍內所有值
- M-N/X 或者 */X 在指定M~N範圍內或整個有效區間內每隔X構建一次
- A,B,...,Z 匹配多個值
為了在系統中生成定時任務，符號H（代表“Hash”，後面用“散列”代替）應該用在可能用到的地方，例如：為十幾個日常任務配置0 0 * * *將會在午夜產生較大峰值。相比之下，配置H H * * * 仍將每天一次執行每個任務，不是都在同一時刻，可以更好的使用有限資源。
符號H可用於範圍，例如，H H(0-7) * * * 代表淩晨0:00到 上午7:59一段時間。你還可以用H代表有或無範圍的區間。
符號H 在一定範圍內可被認為是一個隨機值，但實際上它是任務名稱的一個散列而不是隨機函數。
需要註意的是，月份中的某天-DOM字段，類似於*/3 或者 H/3 的短周期由於月份的天數不固定，在大多數月尾總不會工作。例如，*/3 將會在一個月裏面的第一天、第四天。。。第31天執行，下個月的那天繼續重復執行。散列一般被選擇在1-28天內，所以H/3將會在跑到月底的3-6天內導致空白。（長時間循環將會導致長度不一，但是這種影響也是不明顯的。）
空行和以#開頭的行將會被認為是註釋。
另外，@yearly, @annually, @monthly, @weekly, @daily, @midnight, 和 @hourly也支持別名。這些使用散列系統自動匹配，例如：@hourly 和 H * * * * 一樣代表一個小時內的任何時刻。@midnight實際上代表淩晨0:00到淩晨2:59之間的一段時間。
例如：
# 每隔15分鐘。(或許:07, :22, :37, :52)
H/15 * * * *
# 每前半小時中每隔10分鐘。 (3次, 或許:04, :14, :24)
H(0-29)/10 * * * *
# 每個工作日從早上9點45分開始到下午3點45分結束這段時間內每間隔2小時的45分鐘那一刻。
45 9-16/2 * * 1-5
#每個工作日從早上9點到下午5點這段時間內每間隔2小時之間的某刻。(或許在上午10:38, 下午12:38, 下午2:38 , 下午4:38)
H H(9-16)/2 * * 1-5
#每月（除了12月）從1號到15號這段時間內某刻。
H H 1,15 1-11 *
附4：jenkins 關閉和重啟方法：
1、關閉Jenkins
只需要在訪問jenkins服務器的網址url地址後加上exit。例如我jenkins的地址http://localhost:8080/，那麽我只需要在瀏覽器地址欄上敲下http://localhost:8080/exit 網址就能關閉jenkins服務.
2、重啟Jenkies
http://localhost:8080/restart
3、重新加載配置信息
http://localhost:8080/reload
附5：錯誤集錦：
1. GitLab: The project you were looking for could not be found.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
解決方案：
查看git用戶是否具有提交到gitlab倉庫的權限
2. Could not open a connection to your authentication agent.
需手動開啟ssh，如下；
eval `ssh-agent -s`
再次執行ssh-add 即可
3. Exception when publishing, exception message [Exec timed out or was interrupted after 120,001 ms
適當調大超時時間，比如調成300000
4. ssh_exchange_identification: Connection closed by remote host
解決方法一. 把SSH連接數改大
修改服務器上的這個文件：/etc/ssh/sshd_config 找到這行 # MaxSessions 10 ：
去掉前面的"#" 並把數字改大，最後重啟sshd service sshd restart 然後重新連接即可.
解決方法二. 每次正常退出SSH連接
每次執行完命令後用輸入"exit" 退出, 防止連接數過多.
附6：svn批量檢測提交shell腳本
見github: https://github.com/saysmy/svnsh
jenkins+gitlab自動化編譯部署方案探索及服務端編譯webpack實戰