架構(gòu)背景：
惠農(nóng)網(wǎng)目前后端采用的微服務(wù)的架構(gòu)，有近100個不同的微服務(wù)。同時前端項目也包括很多單頁的h5項目，還有一些基于微前端的中臺項目。所以前后端的項目在gitlab倉庫里面有200+個不同的倉庫。
以前的情況：
之前的上線和發(fā)布流程是基于JetBrains公司的TeamCity的免費(fèi)版本結(jié)合Ansible來完成的，隨著項目越來越多，TeamCity免費(fèi)版本凸顯了越來越多的問題：
免費(fèi)的TeamCity只支持配置100個項目， 目前我們的項目已經(jīng)大大超過了支持的上限，沒有辦法進(jìn)行繼續(xù)添加了。
每次創(chuàng)建一個TeamCity的項目都是基于以前的配置進(jìn)行copy，然后再去修改一些配置，在配置的過程中容易出現(xiàn)錯誤，排查和定位比較花費(fèi)時間。
整體的打包、測試、部署、上線的流程都是通過復(fù)制的方法來創(chuàng)建的。如果要進(jìn)行修改，則需要把這些項目一個一個的修改，改動的成本較大。
整個流程都是管控在研發(fā)手中，上線的時候缺乏質(zhì)量的管控，容易引發(fā)線上的bug，并且有時候發(fā)布是靜默發(fā)布，對應(yīng)的測試和項目負(fù)責(zé)人把控力度不足。
如果對于一個或者少數(shù)項目修改上線流程，沒有記錄的地方，導(dǎo)致接手的人對于上線流程把控不嚴(yán)。
打包和發(fā)布流程隔離，實(shí)現(xiàn)打包自動化，發(fā)布手動化的兩個階段， 達(dá)到由研發(fā)人員根據(jù)hook來自動打包，由測試人員手動進(jìn)行發(fā)布，這樣測試人員可以馬上進(jìn)行發(fā)布后的驗(yàn)證。
統(tǒng)一通知流程，在不同的階段失敗和成功都進(jìn)行統(tǒng)一通知。
基于以上的情況，決定把TeamCity上面的項目遷移到Jenkins上面，并且用IaC的理念重構(gòu)整個ci/cd的流程。
遷移改造的方案：
所有的部署的流程全部代碼化，利用jenkins的shared library插件，把項目的發(fā)布流程pipeline作為一個gitlab上的項目進(jìn)行管理，這樣通過代碼就可以進(jìn)行流程的統(tǒng)一管理和修改。
每個項目中加入ci的必要配置的配置文件，配置文件抽象出來就是項目四要素（項目所屬倉庫的:group，項目名稱:project，項目部署機(jī)器: host, 項目部署端口: port）。
利用gitlab的global server hook來監(jiān)聽ci配置文件的變化，如果是有新增或者修改，則通過jenkins的api來創(chuàng)建和修改對應(yīng)的項目的發(fā)布頁面，通過gitlab的api來創(chuàng)建對應(yīng)的項目的webhook的配置
利用jenkins的配置文件，每個項目都根據(jù)配置文件，構(gòu)建不同的發(fā)布頁面，研發(fā)人員可以完全不關(guān)注jenkins的存在。減輕研發(fā)的思維負(fù)擔(dān)。
改造得到的成果
項目個數(shù)沒有上限，并且統(tǒng)一在一個jenkins環(huán)境就可以看到所有不同的項目。
測試環(huán)境流程和生產(chǎn)環(huán)境的流程全部在一個gitlab的倉庫，用代碼進(jìn)行管理，有g(shù)itlab的操作記錄，更好的管控每次的修改。
統(tǒng)一修改流程，只需要修改統(tǒng)一的流程，并會影響所有的項目，對于ci/cd流程的改動達(dá)到了一次修改，全局生效的效果。
對于新增項目配置，只需要一個配置文件即可完成所有的流程，創(chuàng)建新項目只需要10秒即可創(chuàng)建完成。
因?yàn)榇虬桶l(fā)布流程隔離，所以發(fā)布或者回滾流程進(jìn)行了統(tǒng)一，一個tag只需要一次打包，就可以完成發(fā)布或者是回滾，并且提示了發(fā)布和回滾的效率。
整體ci的架構(gòu)流程圖
整體項目的工作流程
- 項目提交Jenkinsfile到gitlab倉庫。
- gitlab倉庫的Global Server Hook感知到Jenkinsfile文件的添加。
- 根據(jù)添加的Jenkinsfile里面的項目信息，初始化構(gòu)建Jenkins的job信息和gitlab的hook配置。
- 項目代碼變化了之后，Jenkins拉取變化的代碼，根據(jù)代碼里面的Jenkinsfile，讀取pipeline-library倉庫的代碼，并且執(zhí)行代碼里面的流程（打包，運(yùn)行單元測試，運(yùn)行靜態(tài)檢查，打包，部署，通知）。
- 如果是線上環(huán)境，構(gòu)建最終發(fā)布頁面，通知測試，手動進(jìn)行發(fā)布。
- 發(fā)布流程則是調(diào)用Ansible寫好的playbook的腳本，進(jìn)行多個服務(wù)器的最終發(fā)布
項目的Jenkinsfile例子截圖
總結(jié)
通過整體流程的改造，使得所有項目的ci/cd的流程一氣呵成。 大大提升了項目的配置和發(fā)布效率，減輕了維護(hù)的成本（研發(fā)人員只需要關(guān)注Jenkinsfile一個配置文件）。 雖然項目中沒有放出所有的代碼，但是這個整體流程已經(jīng)說明的很明白了，如果想要溝通和了解細(xì)節(jié)， 可以進(jìn)行留言。歡迎大家提出更好的想法。
