DevOps是Development和Operations的組合詞，作為一名軟體工程師或者系統架構師，對於系統的開發和部署需要有充分的瞭解和把控。
下面我們通過一個故事，把軟體釋出中的分環境配置和版本檢查的解決方案為你娓娓道來......
本文涉及到的所有程式碼可以在這裡 ? 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增加如下幾個環境的配置，並指定配置路徑：
<profiles>
<!-- 分環境profile> -->
<profile>
<id>dev</id>
<!-- 如果dev帶上activeByDefault，會預設將dev下的配置複製到config目錄下-->
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<env>dev</env>
<package.target>dev</package.target>
<spring.profiles.active.value>dev</spring.profiles.active.value>
<yui.skip>true</yui.skip>
<config.path>src/main/resources/config/dev</config.path>
</properties>
</profile>
<!--sit-->
<profile>
<id>sit</id>
<properties>
<env>sit</env>
<package.target>sit</package.target>
<spring.profiles.active.value>sit</spring.profiles.active.value>
<yui.skip>false</yui.skip>
<config.path>src/main/resources/config/sit</config.path>
</properties>
</profile>
<!-- uat -->
<profile>
<id>uat</id>
<properties>
<env>uat</env>
<package.target>uat</package.target>
<spring.profiles.active.value>uat</spring.profiles.active.value>
<yui.skip>false</yui.skip>
<config.path>src/main/resources/config/uat</config.path>
</properties>
</profile>
<!--sandbox-->
<profile>
<id>sandbox</id>
<properties>
<env>sandbox</env>
<package.target>sandbox</package.target>
<spring.profiles.active.value>sandbox</spring.profiles.active.value>
<yui.skip>false</yui.skip>
<config.path>src/main/resources/config/sandbox</config.path>
</properties>
</profile>
<!--prod-->
<profile>
<id>prod</id>
<properties>
<env>prod</env>
<package.target>prod</package.target>
<spring.profiles.active.value>prod</spring.profiles.active.value>
<yui.skip>false</yui.skip>
<config.path>src/main/resources/config/prod</config.path>
</properties>
</profile>
</profiles>
複製程式碼然後在打包專案的時候通過-P引數指定環境就行了。例如打包uat環境：
$ mvn install -Puat
複製程式碼指定環境打包的缺點
首先就是慢，也可說浪費咖啡。很多大型專案每次從編譯到拉檔案都要半個多小時。
那怎麼節省釋出的時間，讓我們早點下班呢？答案就是所有環境一個包。
5個環境就能節省2個小時，太值了！
只打一個包
怎麼所有環境一個包呢？
首先在pom.xml配置maven-resources-plugin外掛，並指定copy-resources的路徑，把所有環境的配置都打到包裡。
<!-- maven-resources-plugin -->
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<id>copy-resources</id>
<phase>validate</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${basedir}/target/classes/config</outputDirectory>
<resources>
<resource>
<directory>${config.path}/</directory>
<filtering>true</filtering>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
複製程式碼然後正常使用mvn install打包。
最後把要釋出的包複製到指定環境機器的磁碟上以後，通過mv命令把需要釋出的環境的配置移動出來。例如釋出sandbox環境：
mv config/sandbox/* config/
複製程式碼當然這個操作不是必須的，比如你在啟動容器的時候指定了當前的環境，然後通過${spring.profile.active}來指定當前讀取哪個目錄下的配置也可以。
版本檢查
現在解決了打包慢的問題，但是怎麼保證運維人員釋出的程式碼版本跟我們功能所在的版本一致呢？
當然可以口頭確認，結果就發生了上面的“慘案”。
那麼我們能不能自己檢查呢？那就要藉助工具了。
git-commit-id-plugin
git-commit-id-plugin是一個外掛，會根據當前分支的版本號生成一個git.properties檔案。
首先在pom.xml引入外掛配置：
<!-- https://github.com/git-commit-id/maven-git-commit-id-plugin -->
<plugin>
<groupId>pl.project13.maven</groupId>
<artifactId>git-commit-id-plugin</artifactId>
<version>${git-commit-id-plugin.version}</version>
<executions>
<execution>
<id>get-the-git-infos</id>
<goals>
<goal>revision</goal>
</goals>
</execution>
</executions>
<configuration>
<!-- 使properties擴充套件到整個maven bulid 週期, Ref: https://github.com/ktoso/maven-git-commit-id-plugin/issues/280 -->
<injectAllReactorProjects>true</injectAllReactorProjects>
<dateFormat>yyyy.MM.dd HH:mm:ss</dateFormat>
<verbose>true</verbose>
<!-- 是否生 git.properties 屬性檔案 -->
<generateGitPropertiesFile>true</generateGitPropertiesFile>
<!--git描述配置,可選;由JGit提供實現; -->
<gitDescribe>
<!--是否生成描述屬性 -->
<skip>false</skip>
<!--提交操作未發現tag時,僅列印提交操作ID -->
<always>false</always>
<!--提交操作ID顯式字元長度,最大值為:40;預設值:7; 0代表特殊意義;-->
<abbrev>7</abbrev>
<!--構建觸發時,程式碼有修改時(即"dirty state"),新增指定字尾;預設值:""; -->
<dirty>-dirty</dirty>
<forceLongFormat>false</forceLongFormat>
</gitDescribe>
</configuration>
</plugin>
複製程式碼接著打包專案，你就可以看到自己編譯的檔案下面多了一個git.properties檔案：
#Generated by Git-Commit-Id-Plugin
#Sat Apr 20 13:08:01 CST 2019
git.branch=master
git.build.host=DESKTOP-12GT5DQ
git.build.time=2019.04.20 13\:08\:01
git.build.user.email=ijiangtao@foxmail.com
git.build.user.name=ijiangtao
git.build.version=1.1.01.01-SNAPSHOT
git.closest.tag.commit.count=
git.closest.tag.name=
git.commit.id=67b60eeffa9deca877c2b9a28d52a40d3ea55444
git.commit.id.abbrev=67b60ee
git.commit.id.describe=67b60ee
git.commit.id.describe-short=67b60ee
git.commit.message.full=\u53D1\u9001\u91CD\u8981\u6570\u636E\u7ED9\u8001\u677F~~~~
git.commit.message.short=\u53D1\u9001\u91CD\u8981\u6570\u636E\u7ED9\u8001\u677F~~~~
git.commit.time=2019.04.20 12\:57\:50
git.commit.user.email=ijiangtao@foxmail.com
git.commit.user.name=ijiangtao
git.dirty=false
git.remote.origin.url=https\://github.com/javastudydemo/jsd-maven.git
git.tags=
git.total.commit.count=2
複製程式碼有了這個檔案，我們就可以清晰地知道生產環境的程式碼是什麼版本了。
需要特別注意的是，使用這個外掛要保證你編譯的專案是有.git目錄的，因為這個外掛要獲取git的提交資訊，如果不使用git進行版本管理的專案，編譯會報錯。
版本檢查地址
下面提供一個Controller來展示git的提交資訊。
package net.ijiangtao.tech.maven.web.controller;
import com.alibaba.fastjson.JSON;
import com.alibaba.fastjson.serializer.SerializerFeature;
import com.wordnik.swagger.annotations.Api;
import com.wordnik.swagger.annotations.ApiOperation;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseBody;
import java.util.*;
import static org.apache.commons.lang3.ObjectUtils.defaultIfNull;
/**
* @author ijiangtao
*/
@Controller
@Api(value = "", description = "git info from git-commit-id-plugin")
public class GitCommitController {
/**
* @return
*/
@RequestMapping("/git/commit/info")
@ResponseBody
@ApiOperation(value = "get commit info", httpMethod = "GET")
public String showGitCommitInfo() {
//git.properties
ResourceBundle resourceBundle = ResourceBundle.getBundle("git", defaultIfNull(null, Locale.getDefault()));
Map<String, String> map = new TreeMap<>();
Enumeration<String> keysEnumeration = resourceBundle.getKeys();
while (keysEnumeration.hasMoreElements()) {
String key = keysEnumeration.nextElement();
map.put(key, resourceBundle.getString(key));
}
return JSON.toJSONString(map, SerializerFeature.PrettyFormat);
}
/**
* @return
*/
@ApiOperation(value = "get commit id", httpMethod = "GET")
@RequestMapping("/git/commit/id")
@ResponseBody
public String showGitCommitId() {
//git.properties
ResourceBundle resourceBundle = ResourceBundle.getBundle("git", defaultIfNull(null, Locale.getDefault()));
return resourceBundle.getString("git.commit.id");
}
}
複製程式碼通過Jetty外掛啟動專案，並訪問SwaggerUI地址 http://localhost:8241/swagger/index.html ，最後通過http://localhost:8241/git/commit/info請求到了我們的git提交資訊。
一般我們為了版本回滾的方便，釋出的時候會通過git commit id進行打包，可以通過機器對比兩者是否一致，達到自動檢查的目的，而不是每次需要人工檢查。
總結
本文講解了使用Maven進行分環境配置和進行釋出版本檢查的一種實現模式，在持續整合/持續部署(CI/CD)的實踐中非常有借鑑意義。