作者：西召
來源：https://juejin.im/post/5cbb1dc751882532ba3e9849
DevOps是Development和Operations的組合詞，作為一名軟件工程師或者系統架構師，對於系統的開發和部署需要有充分的瞭解和把控。
下面我們通過一個故事，把軟件發佈中的分環境配置和版本檢查的解決方案為你娓娓道來......
本文涉及到的所有代碼可以在這裡maven-devops(https://github.com/javastudydemo/jsd-maven/tree/master/maven-devops)獲取。
一個故事(事故)
試想這樣一個場景，你做了一個功能：每天凌晨4點去某個系統拉取一份數據郵件，然後第二天上午6點以郵件的形式發給你的老闆。
首先你在自己的電腦上開發和測試，確認開發完成以後，把代碼打包放到測試服務器上跑了一下。
你找到可愛的測試小妹妹，經過嚴格的測試，確認通過了所有測試用例。最後你不忘恭維一下測試小妹妹最近燙的頭髮真漂亮，並含蓄地表示有空想請她看最近上映的漫威電影。( 而實際上測試小妹妹的頭髮沒有燙過，她也沒聽懂你的暗示，她更不喜歡看漫威的電影，最最關鍵的是，你根本沒有時間請別人看電影——這個問題問一下你家裡洗衣機裡靜靜趟了兩星期的襪子就知道了。)
你把自己的代碼合併到主分支，然後通知發佈人員把代碼發佈到生產環境。當你收到運維人員發佈成功的提醒的時候，抬頭看看錶已經是午夜兩點了。你喝乾淨杯子裡的咖啡，深深懶腰，搭車回家了。
第二天上午，你在一陣急促的電話鈴聲中被吵醒，電話那頭的聲音頓時讓你睏意全無：老闆沒有收到任何郵件，郵件裡的資料要在2h以後的一個重要會議中使用！
......
數據終於是想方設法搞到了，但疲憊、恐懼、羞恥和自責已經淹沒了你的頭腦，你要搞事情了：查到原因，徹底解決這個問題！
笨人和聰明人的差異就在於，笨人只會不停地栽跟頭，而聰明人跌倒以後爬起來，不忘把坑填上，還會在旁邊立個碑，以警後人 —— 能做到這一點的幾乎就是偉人了。
分環境
前面提到了你自己開發、給測試小妹妹測試以及給運維人員發佈，一共三個環境，而實際上一個軟件系統的環境往往不止這些。
常用的環境有：dev、sit、uat、sandbox、pro。
- dev就是開發環境(Development Environment)，每個開發人員自己搭建的環境，當然一般也會在公司內部服務器搭建一些諸如數據庫、分佈式服務等公用的開發環境服務。
- sit就是系統集成測試環境(System Integration Testing Environment)，主要目的是把系統的各個模塊作為一個組進行測試。
- uat就是用戶驗收測試環境(User Acceptance Testing Environment)，一般是對系統比較熟悉的人，對開發成果進行驗收的環境。
- sandbox就是沙箱環境(Sandbox Environment)，這個環境為的是最真實地模擬生產環境。
- pro就是生產環境(Production Environment)，這個環境是我們最終交付的產品所運行的環境。
為什麼要有這麼多環境呢？答案是形勢所迫。隨著軟件開發的分工日益精細化和軟件系統的日益複雜化，不同環境所承擔的職責不同，但最終目的是一樣的：提高效率、保證質量、節約成本、保證收益。
關於分環境的思想這裡就不多講了，下面要講的一個問題是分環境是如何實現的？
分環境的實現方式有很多Spring Profile、Spring Boot等等都有不同的實現。
下面講一個使用 maven profiles 實現分環境配置的方式。
分環境實現
比如我在不同的環境需要提供不同的配置文件，怎麼實現呢？
首先在pom.xml增加如下幾個環境的配置，並指定配置路徑：
然後在打包項目的時候通過-P參數指定環境就行了。例如打包uat環境：
$ mvn install -Puat
指定環境打包的缺點
首先就是慢，也可說浪費咖啡。很多大型項目每次從編譯到拉文件都要半個多小時。
那怎麼節省發佈的時間，讓我們早點下班呢？答案就是所有環境一個包。
5個環境就能節省2個小時，太值了！
只打一個包
怎麼所有環境一個包呢？
首先在pom.xml配置maven-resources-plugin插件，並指定copy-resources的路徑，把所有環境的配置都打到包裡。
然後正常使用mvn install打包。
最後把要發佈的包複製到指定環境機器的磁盤上以後，通過mv命令把需要發佈的環境的配置移動出來。例如發佈sandbox環境：
mv config/sandbox/* config/
當然這個操作不是必須的，比如你在啟動容器的時候指定了當前的環境，然後通過${spring.profile.active}來指定當前讀取哪個目錄下的配置也可以。
git分支管理
根據每個環境打不同的包，發佈一個新的feature到生產需要類似下面這樣的流程：
- 首先用 develop 分支 打包，發佈sit環境，測試通過合併到 release 分支；
- 然後用 release 分支 打包，發佈到uat環境，測試通過合併到 master 分支(打 tag)；
- 最後用 master 分支 打包，發佈到生產環境。開發只能在 develop分支和feature分支改代碼，master分支與線上運行的代碼保持一致。
打一個包發佈所有環境以後，分支管理模式將改為：
- 功能在feature分支自測成功以後，將代碼合併到release分支，測試人員在release分支測試並最終發佈生產。
- 當代碼成功發佈生產以後，將release分支代碼合併到master 分支。
上圖演示了多環境多包發佈和多環境單包發佈的簡要流程，下面做一下補充說明。
多環境多包發佈
- 每個環境分別打包發佈，直至最後所有環境測試通過發佈生產。
- 最後將master分支的代碼merge到develop分支，保證develop分支的代碼與線上代碼一致。
多環境單包發佈
- 只在release分支打一個包，供所有環境發佈。測出bug則重新打包，直至所有bug都測試通過。
- 使用release分支打的包發佈成功以後，會將release分支的代碼merge到master分支備份，方便日後hotfix等。
- 最後將master分支的代碼merge到develop分支，保證develop分支的代碼與線上代碼一致。
版本檢查
現在解決了打包慢的問題，但是怎麼保證運維人員發佈的代碼版本跟我們功能所在的版本一致呢？
當然可以口頭確認，結果就發生了上面的“慘案”。
那麼我們能不能自己檢查呢？那就要藉助工具了。
git-commit-id-plugin
git-commit-id-plugin是一個插件，會根據當前分支的版本號生成一個git.properties文件。
首先在pom.xml引入插件配置：
接著打包項目，你就可以看到自己編譯的文件下面多了一個git.properties文件：
有了這個文件，我們就可以清晰地知道生產環境的代碼是什麼版本了。
需要特別注意的是，使用這個插件要保證你編譯的項目是有.git目錄的，因為這個插件要獲取git的提交信息，如果不使用git進行版本管理的項目，編譯會報錯。
版本檢查地址
下面提供一個Controller來展示git的提交信息。
通過Jetty插件啟動項目，並訪問SwaggerUI地址 http://localhost:8241/swagger/index.html ，最後通過http://localhost:8241/git/commit/info請求到了我們的git提交信息。
一般我們為了版本回滾的方便，發佈的時候會通過git commit id進行打包，可以通過機器對比兩者是否一致，達到自動檢查的目的，而不是每次需要人工檢查。
總結
本文講解了使用Maven進行分環境配置和進行發佈版本檢查的一種實現模式，在持續集成/持續部署(CI/CD)的實踐中非常有借鑑意義。
閱讀更多 Java面經l 的文章
