作者：西召
来源：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 的文章
