問題背景
想起初來公司時，我們還是在釋出機上直接執行釋出指令碼來執行和部署服務，並且正式環境和測試環境的指令碼都在一起，直接手動操作指令碼時存在比較大的風險就是將環境部署錯誤，並且當時指令碼部署邏輯還沒有檢測機制，服務部署起來後，還必須登入到對應機器檢視服務是否正確啟動，整個部署過程可以說是很折磨人了。於是，我開始著手改善這塊。
如何最佳化
第一，整個編譯部署過程將不再允許登入到釋出機手動執行釋出指令碼了，這樣的風險性比較大，決定採用jenkins來完成編譯和釋出的工作，這樣能讓開發者透過介面操作來進行編譯部署。
第二，之前指令碼缺少檢測機制，決定改善指令碼，首先在部署前，指令碼需要檢測對應的服務的配置檔案是否符合標準，我們的配置檔案是json格式，其次在部署完成後，檢測服務是否正常啟動，如果沒有啟動，則嘗試再次部署，直到失敗3次後將不再重試。
部署模式思考?
在決定朝著這兩個最佳化點進行最佳化後，我開始思考最終的部署模式，測試環境肯定是經常要部署和釋出的，而正式環境則不需要經常釋出，並且要謹慎釋出。
所以我考慮在測試環境做個自動釋出的功能，到程式碼合併到測試環境的分支(測試環境永遠用固定的分支名)時，會觸發jenkins的webhook機制來自動編譯和釋出到測試環境。
而對於正式環境而言，則不採用這種機制，為了保證正式環境的安全，還需要保證程式碼的快速回滾，基於此，正式環境我將採用打tag的方式進行釋出，每次釋出後會生成一個tag，回滾時則可以基於tag快速回滾。關於tag的釋出模式將在下一篇文章再展開，現在我們先來看看如何
基於分支做自動釋出。
配置webhook實現自動編譯與釋出
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“ 來觸發編譯工作。
gitlab 推送配置
在gitlab中配置特定分支產生push事件時觸發jenkins的回撥任務,這裡假設我的測試分支名是test，以後所有測試環境的功能都需要合併到test分支進行測試，所以我在push event下面配置了test，你也可以配置成其他分支。
測試自動編譯過程
這樣，當我在test分支去進行push操作時，將會觸發jenkins 特定專案執行其pipeline，完成編譯和釋出工作。
在gitlab下方可以點選Test選定特定的事件來測試下整個自動編譯過程。
關於jenkins的釋出和編譯指令碼由於涉及到公司隱私，我這裡就不展開了，最終jenkins的pipeline 也是執行的shell指令碼去釋出機上去進行編譯和釋出。關於哪個服務需要釋出到哪臺機器上，我們是配置到了資料庫裡，然後指令碼會根據要部署的服務從資料庫中讀取要部署的機器，然後將編譯好的可執行程式透過scp傳送到對應機器，然後遠端執行ssh命令完成服務的啟動。
整個專案的釋出部署拓撲圖如下，其實也完全可以將gitlab和jenkins放到一臺機器上。
