DevOps是Development和Operations的组合词,做为一名软件工程师或者系统架构师,对于系统的开发和部署须要有充分的了解和把控。html
下面咱们经过一个故事,把软件发布中的分环境配置和版本检查的解决方案为你娓娓道来......java
本文涉及到的全部代码能够在这里 👉 maven-devops 获取。git
试想这样一个场景,你作了一个功能: 天天凌晨4点去某个系统拉取一份数据邮件,而后次日上午6点以邮件的形式发给你的老板。github
首先你在本身的电脑上开发和测试,确认开发完成之后,把代码打包放到测试服务器上跑了一下。web
你找到可爱的测试小妹妹,通过严格的测试,确认经过了全部测试用例。最后你不忘恭维一下测试小妹妹最近烫的头发真漂亮,并含蓄地表示有空想请她看最近上映的漫威电影。( 而实际上测试小妹妹的头发没有烫过,她也没听懂你的暗示,她更不喜欢看漫威的电影,最最关键的是,你根本没有时间请别人看电影——这个问题问一下你家里洗衣机里静静趟了两星期的袜子就知道了。)spring
你把本身的代码合并到主分支,而后通知发布人员把代码发布到生产环境。当你收到运维人员发布成功的提醒的时候,抬头看看表已是午夜两点了。你喝干净杯子里的咖啡,深深懒腰,搭车回家了。shell
次日上午,你在一阵急促的电话铃声中被吵醒,电话那头的声音顿时让你困意全无:老板没有收到任何邮件,邮件里的资料要在2h之后的一个重要会议中使用!数据库
......apache
数据终因而千方百计搞到了,但疲惫、恐惧、羞耻和自责已经淹没了你的头脑,你要搞事情了:查到缘由,完全解决这个问题!json
笨人和聪明人的差别就在于,笨人只会不停地栽跟头,而聪明人跌倒之后爬起来,不忘把坑填上,还会在旁边立个碑,以警后人 —— 能作到这一点的几乎就是伟人了。
前面提到了你本身开发、给测试小妹妹测试以及给运维人员发布,一共三个环境,而实际上一个软件系统的环境每每不止这些。
经常使用的环境有: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}
来指定当前读取哪一个目录下的配置也能够。
根据每一个环境打不一样的包,发布一个新的feature到生产须要相似下面这样的流程:
打一个包发布全部环境之后,分支管理模式将改成:
上图演示了多环境多包发布
和多环境单包发布
的简要流程,下面作一下补充说明。
如今解决了打包慢的问题,可是怎么保证运维人员发布的代码版本跟咱们功能所在的版本一致呢?
固然能够口头确认,结果就发生了上面的“惨案”。
那么咱们能不能本身检查呢?那就要借助工具了。
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)的实践中很是有借鉴意义。