分环境

前面提到了你自己开发、给测试小妹妹测试以及给运维人员发布，一共三个环境，而实际上一个软件系统的环境往往不止这些。

常用的环境有：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分支管理

根据每个环境打不同的包，发布一个新的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引入插件配置：

<!-- 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 2019git.branch=mastergit.build.host=DESKTOP-12GT5DQgit.build.time=2019.04.20 13:08:01git.build.user.email=ijiangtao@foxmail.comgit.build.user.name=ijiangtaogit.build.version=1.1.01.01-SNAPSHOTgit.closest.tag.commit.count=git.closest.tag.name=git.commit.id=67b60eeffa9deca877c2b9a28d52a40d3ea55444git.commit.id.abbrev=67b60eegit.commit.id.describe=67b60eegit.commit.id.describe-short=67b60eegit.commit.message.full=u53D1u9001u91CDu8981u6570u636Eu7ED9u8001u677F~~~~git.commit.message.short=u53D1u9001u91CDu8981u6570u636Eu7ED9u8001u677F~~~~git.commit.time=2019.04.20 12:57:50git.commit.user.email=ijiangtao@foxmail.comgit.commit.user.name=ijiangtaogit.dirty=falsegit.remote.origin.url=https://github.com/javastudydemo/jsd-maven.gitgit.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进行打包，可以通过机器对比两者是否一致，达到自动检查的目的，而不是每次需要人工检查。

DevOps: 项目多环境配置和健康检查