運維號
雖然我只是個開發人員，但是很多時候都是我們自己完成環境部署，目前我們測試環境實現了自動化部署，是基於Jenkins來做的；生產環境暫時還是【人肉】部署。整體的發佈水平和很多公司還是有很大的差距，不過公司缺少一些基礎平臺，我們也只能自己想辦法。
自動化發佈，前置工作有很多
通過Jenkins實現自動化發佈的過程很簡單：
開發人員把代碼通過git或者svn提交；
Jenkins可以通過手動或定時的方式啟動，會更新最新的代碼，跑全量的測試用例，測試通過後進行代碼的部署；部署的過程都是提前寫好的腳本，比如通過什麼命令打包，把包放到哪臺服務器的哪個目錄下面，通過什麼命令停止和啟動（重啟）服務。（具體的安裝和配置，搜索一下會找到很多資料）
自動化發佈看起來非常簡單，但實際上前置工作很多：
- 需要有代碼版本控制工具：這個問題不大，基本上每個公司都會有，最常用的git和svn；需要告訴Jenkins項目的代碼在哪裡。
- 自動化構建工具：如Maven、Gradle、Ant，我們基本都用Maven，個別特別老的項目用的Ant；需要告訴Jenkins項目執行什麼命令可以打包。
- 整包發佈：我瞭解還是有不少公司喜歡增量發佈，但是我覺得如果能做到全量發佈的話是最好了，能避免很多的問題。
- 單元測試：很多人會忽視這個問題，我還是覺得很有必要的；寫單元測試要發自內心地覺得有用，而不是為了追求測試覆蓋度，不是為了做給領導看。
- 灰度發佈和回滾：這一點我們也沒有做到，上線就是全部都上線，有問題的話就全部回退；我們項目儘量做到了【人肉灰度發佈】，也就是先更新一個server，然後驗證通過之後，再更新下一個；回滾也是人肉操作。
- 容器：要是公司用到了容器的話，那麼自動化發佈會容易一些...
人肉發佈，想盡辦法減少工作量
因為很多基礎平臺沒有（我們公司很多工作都做了細分），一些事情的推進不是開發就可以推進的，通常需要很多部門的配合；所以生產環境依然還是手動發佈。
拆包：我們項目是純接口的項目，沒有頁面；項目被拆成了幾個包，有單獨一個包是對外提供服務的，也就是說，其餘幾個包隨時可以在線發佈，反正對用戶是無感的；
編寫各種shell腳本：既然做不到自動化發佈，那麼就讓發佈儘可能簡單；可以把發佈過程中一系列的命令，都寫到shell腳本里面完成；
偽灰度發佈：對外提供接口的包被部署在N個server上（使用Spring Boot內嵌的Tomcat），前面掛著Nginx，Nginx可以監控每個server（節點）的存活，所以發佈的時候先停掉一個server做程序更新，Nginx會知道這個server不存活，這時候不會再發送新的請求到這個server上，直到程序更新完成啟動。
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。
分享到:
