問題背景

想起初來公司時，我們還是在發(fā)布機上直接執(zhí)行發(fā)布腳本來運行和部署服務，并且正式環(huán)境和測試環(huán)境的腳本都在一起，直接手動操作腳本時存在比較大的風險就是將環(huán)境部署錯誤，并且當時腳本部署邏輯還沒有檢測機制，服務部署起來后，還必須登錄到對應機器查看服務是否正確啟動，整個部署過程可以說是很折磨人了。于是，我開始著手改善這塊。

如何優(yōu)化

第一，整個編譯部署過程將不再允許登錄到發(fā)布機手動執(zhí)行發(fā)布腳本了，這樣的風險性比較大，決定采用jenkins來完成編譯和發(fā)布的工作，這樣能讓開發(fā)者通過界面操作來進行編譯部署。

第二，之前腳本缺少檢測機制，決定改善腳本，首先在部署前，腳本需要檢測對應的服務的配置文件是否符合標準，我們的配置文件是json格式，其次在部署完成后，檢測服務是否正常啟動，如果沒有啟動，則嘗試再次部署，直到失敗3次后將不再重試。

部署模式思考🤔

在決定朝著這兩個優(yōu)化點進行優(yōu)化后，我開始思考最終的部署模式，測試環(huán)境肯定是經常要部署和發(fā)布的，而正式環(huán)境則不需要經常發(fā)布，并且要謹慎發(fā)布。

所以我考慮在測試環(huán)境做個自動發(fā)布的功能，到代碼合并到測試環(huán)境的分支(測試環(huán)境永遠用固定的分支名)時，會觸發(fā)jenkins的webhook機制來自動編譯和發(fā)布到測試環(huán)境。

而對于正式環(huán)境而言，則不采用這種機制，為了保證正式環(huán)境的安全，還需要保證代碼的快速回滾，基于此，正式環(huán)境我將采用打tag的方式進行發(fā)布，每次發(fā)布后會生成一個tag，回滾時則可以基于tag快速回滾。關于tag的發(fā)布模式將在下一篇文章再展開，現在我們先來看看如何
基于分支做自動發(fā)布。

配置webhook實現自動編譯與發(fā)布

jenkins 安裝 Generic Webhook Trigger 插件

在Jenkins的Manage Jenkins→Plugins→Available Plugins 中安裝Generic Webhook Trigger 插件，再去到項目中查看Build Triggers ，就能看到Generic Webhook Trigger選項了。

在Generic Webhook Trigger 配置頁下方有個token的配置，這個我一般配置成服務名，當配置了token后，到時候gitlab就可以通過url ”http://JENKINS_URL/generic-webhook-trigger/invoke?token=TOKEN_HERE“ 來觸發(fā)編譯工作。

gitlab 推送配置

在gitlab中配置特定分支產生push事件時觸發(fā)jenkins的回調任務,這里假設我的測試分支名是test，以后所有測試環(huán)境的功能都需要合并到test分支進行測試，所以我在push event下面配置了test，你也可以配置成其他分支。

測試自動編譯過程

這樣，當我在test分支去進行push操作時，將會觸發(fā)jenkins 特定項目執(zhí)行其pipeline，完成編譯和發(fā)布工作。

在gitlab下方可以點擊Test選定特定的事件來測試下整個自動編譯過程。

關于jenkins的發(fā)布和編譯腳本由于涉及到公司隱私，我這里就不展開了，最終jenkins的pipeline 也是執(zhí)行的shell腳本去發(fā)布機上去進行編譯和發(fā)布。關于哪個服務需要發(fā)布到哪臺機器上，我們是配置到了數據庫里，然后腳本會根據要部署的服務從數據庫中讀取要部署的機器，然后將編譯好的可執(zhí)行程序通過scp發(fā)送到對應機器，然后遠程執(zhí)行ssh命令完成服務的啟動。

整個項目的發(fā)布部署拓撲圖如下，其實也完全可以將gitlab和jenkins放到一臺機器上。