jenkins+gitlab自動化編譯部署方案探索及服務端編譯webpack實戰

時間 2019-11-17

標籤 jenkins+gitlab jenkins gitlab 自動化編譯部署方案探索服務 webpack 實戰欄目自動化構建简体版

原文原文鏈接

一. 背景

以前咱們的開發流程爲在本地進行webpack打包編譯，而後svn提交源代碼和編譯後的代碼。同時每次提交前也會從svn更新源代碼和編譯後的代碼。這樣作有幾個缺點：css

1. svn 更新和提交編譯後的代碼形成大量衝突文件html

2. 因爲咱們使用非覆蓋式發佈的命名方式，在通過小組多人屢次優化提交測試以後，在整理須要發佈的文件列表時，很容易遺漏一些文件webpack

3. 在涉及到多人開發同一功能時容易產生代碼被覆蓋、人工安排發佈優先級、手動註釋他人未上線代碼等狀況git

4. svn的分支開發繁瑣不友好，加劇工做量github

最不能容忍的是第一第二點，因而咱們改爲服務端打包編碼，本地只提交和更新源代碼，這樣就會大大減小衝突。同時，利用jenkins自動把服務端打包編譯後的代碼部署到測試和線上環境，省去了手動整理待發布文件列表的麻煩，也避免了發佈文件遺漏的狀況。爲了提升開發流程質量，科學友好的規範開發流程，咱們選擇gitlab做爲新的代碼倉庫，經過分支管理和代碼review來提升開發效率，減小發布錯誤。web

二. 自動化部署架構

完成功能：

1. 代碼倉庫用gitlab託管，使用AoneFlow分支管理模式（阿里命名的一種分支管理模式，借鑑於gitflow, githubflow和gitlabflow）。shell

2. 源代碼合併到測試分支後，jenkins自動打包編譯並將編譯後的代碼部署到測試環境。api

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&#47;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:89w3fseydf96934hy@10.95.10.10: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 *