做這件事的起因是因爲公司處於高速發展階段，前端的代碼也在逐步從原來的ko、jquery轉變成現在的react，因此也出現了構建一個版本需要分別打包，然後手動合併的情況。以此爲契機，我開始了整合前端資源，搭建符合公司現有業務場景的自動化構建流程。
主要用到的工具:gitlab、Jenkins、sonarqube
主要模塊:任務管理、分支管理、Jenkins工作流、質量檢測、資源發佈。
講任務管理之前我先提一下我們公司的代碼管理流程，因爲它決定了任務管理的切入點在哪，我們公司的代碼管理類似於gitflow，但是也在此流程上做了一些調整以適應公司的現狀，因此每次發版之前我們都會創建一個對應的發版分支release，以便開發者將自己的feature代碼合併到當前分支（可以看下圖），所以任務管理模塊的主要功能就是管理release走向，我們會提供release創建暫且就叫做task，同時將task關聯到jenkins、gitlab、運維發佈系統。這便是任務管理模塊所要做的事。
這裏大家可能會有疑問，分支管理不是有gitlab嗎？還有一些輔助的工具比如sourceTree、Tower等。其實呢gitlab有很多很強大的功能需要我們去定製。比如
-
上面我提到每次發版都會新建發版分支release，通常我們會從master創建一個新的branch。而這裏就有一個注意點(假如創建出來的分支名稱叫A)，爲了當前分支代碼不被其他分支污染，通常會將分支A設置爲protected，如果我們手動在gitlab中設置，那麼就顯的很不自動了，這與我們的標題就不符了。這時候我們可以通過調用gitlab的api來實現這個步驟。
-
爲了把控任務的走向，我們會通過很多webhooks來本地記錄分支的狀態，比如feature會通過merge request的方式提交代碼給release，然後由管理者去處理，具體的處理結果我們就會通過webhooks關聯到我們的任務中。這其實也是分支管理的一部分
其實我們還提供了分支的創建刪除，提供了一些實時的統計數據，目的是爲了讓開發者在同一個地方完成所有的工作。
有了發版分支，接下來就要創建環境去執行項目的build，這一步其實蠻關鍵的，構建服務在創建完分支之後自動調用jenkins api來完成job的創建，這裏小小的吐槽一下，jenkins的api寫的確實有點…接受參數都是xml，讓我想起了早些年開發微信公衆號的場景😂。在job創建時重點關注以下幾個點(括號裏是xml中的節點名稱)
1.構建時的分支(hudson.plugins.git.BranchSpec)
2.gitlab證書id(credentialsId)
3.構建腳本(command)
說一下構建腳本，主要是用shell，實現的功能包括了獲取資源、代碼校驗(包含了eslint和其他庫合法性的校驗，具體的大家可以根據業務來定)、webpack打包、提交dist到資源倉(發版)、消息通知。具體代碼就不貼了
這一塊我放到後面和校驗一起去說
這裏的發佈系統是我司自己搭建的，也就不過多的解釋了，主要做的事就是把打包好的資源發佈到線上。
上面我簡單的把每一個模塊做了闡述，其實大部分功能都是運行在我們自建的服務中，作爲一個幫助開發者簡化流程的工具，我們也要考慮使用者的感受，所以我們也提供了管理端，展示任務時間軸，構建狀態，代碼質量指標等等。
隨着公司逐漸的壯大，團隊人數的增加帶來了很多高併發，但易忽視的問題，就拿發版流程來說，由最初的開發->測試->線上的三步操作衍生出開發->測試->灰度->線上四步。看起來沒什麼問題，隨着業務碎片化，微服務化，灰度到線上這一步出現了弊端，開發者無法把控灰度和線上之間的同步，品牌之間的同步。導致每到發佈日，我們都得通宵去驗證測試環境，灰度環境是否正確。
後來我們嘗試着去掉灰度，只保留測試和線上，但線上會保留多個版本，最新版本驗證通過之後做流量切換。這保證了發佈效率的同時，也爲提供了很好的回滾方式。但是這樣的流程迫使我們再一次去梳理前端自動化流程，去思考如何去適應。
2019年的某一天，我們幾個小夥伴再一次來到“小黑屋”,一起探討如何優化前端構建流程。多版本發佈帶給我們幾個難題
爲此我們做出瞭如下調整，所有分支創建權限移交至manager，同時記錄分支信息，feature向release/develop提交merge request時增加合法性校驗，驗證是否同步master，組件庫版本等信息。release構建時增加上訴合法性校驗的同時，關聯同一項目不同任務狀態的判斷，保證release包含所有預發佈功能。同時所有驗證失敗結果實時通知到manager/developer。
接下來我們說說除了校驗分支的同時我們還做了哪些質量檢測。
#eslint
{
cp -v -r /Users/android/pc/eslint/eslintrc.js /Users/android/.jenkins/workspace/$1/.eslintrc_copy.js
node ./node_modules/eslint/bin/eslint.js -c .eslintrc_copy.js --ext .jsx,.js,.ts,.tsx src --ignore-path .eslintignore
} || {
send $2 $5 'fail' $1 'eslint驗證失敗' 'eslint'
exit 1
}
同時也會生成相應的報告
結果會展示在sonarqube服務中供大家查看，這裏簡單吹一下sonarqube，作爲一個開源工具做的真的很nice，通過他可以查出一些被忽略的問題，比如定位BUG，統計單元測試情況等等，有興趣的可以去看看sonarqube
到這裏已經快接近尾聲了，總結一下，我們通過搭建服務將gitlab和jenkins做了連接，同時提供管理端來統一處理任務。
- 作爲開發者只關注自己的開發任務，代碼質量等，擺脫了以往全過程參與的狀況。
- 作爲項目管理者，簡化發佈流程，不需要手動打包，將目光轉移到代碼質量、業務實現上。
- 作爲構建服務,凡是能讓我去解決的都不應該讓開發者或者管理者去處理
最後的最後再給大家分享點我自己踩的坑
-
1.jenkins創建任務時如何獲取創建對應的xml？
答：訪問http://localhost:8080/jenkins任務名稱/config.xml你就明白了，前提你要搭建好jenkins。
-
2.jenkins api都有哪些，具體該怎麼使用？
答：推薦使用node-jenkins-api
-
3.gitlab api使用要注意什麼？
答：首先你要確認自己的gitlab版本，然後確認調用v3還是v4的api，二者是有區別的。其次你要注意gitlab的驗證，其實也不難，主要創建一個Private token然後配置在你的header中就可以了