多环境开发(yaml文件版)

我们在自己的开发中是自己环境

测试 生产的环境都不同

多环境分为 两个步骤

设置环境

生产环境 开发环境 测试环境

手搓三个环境

设置应用环境

应用pro配置

# 应用环境
spring:profiles:active: pro---
# 设置环境
# 生产环境
spring:profiles: pro
server:port: 80---
# 开发环境
spring:profiles: dev
server:port: 81---
# 测试环境
spring:profiles: test
server:port: 82

改成替用键

注意要用 --- 分隔开环境

# 应用环境
spring:profiles:active: pro---
# 设置环境
# 生产环境
server:port: 80
spring:config:activate:on-profile:
---
# 开发环境
server:port: 81
spring:config:activate:on-profile:
---
# 测试环境
server:port: 82
spring:config:activate:on-profile: 

小结

多环境开发(多文件版)

这边写了的是三个配置文件

每个配置文件里面都有端口

在主配置里面写的使用的哪个配置

这样我们拿到项目经理给的配置文件

我们只需要修改主启动配置文件就行了

多环境开发(properties版)

早期boot推荐的制作方式

主配置文件

配置信息

所以只是书写格式不同而已

多环境分组管理

我们根据功能对配置文件中的信息进行拆分 并且制作成了独立的配置文件

是用include实行在激活指定环境的情况下 同时对多个环境进行加载使其生效

多个环境间使用逗号分隔

我们首先写主配置文件

把多个配置环境都加载进来

我们启动 要把要启动的信息包含进去

注意后加载的配置覆盖先加载的覆盖

但是主启动里面的配置

是最后加载的

所以所有的配置主要还是按照主启动里面的配置为准

这样就能避免出现这样的问题

但是这种格式并不适用于我们现在的开发

属性太繁琐

我们现在都在用group属性(spring 2.4出现的)

组

设置了若干环境组

spring:profiles:active: devgroup:"dev": devDB,devMVC"pro": proDB,proMVC

小结

多环境开发过程中使用group属性设置配置文件分组

便于线上维护和管理

多环境开发控制

究竟是springboot依赖maven运行

还是maven依赖springboot运行呢

springboot运行时依赖maven里面的坐标配置

没有maven环境springboot都无法去运行

那么maven得首先开发

以maven的配置为主

我们可以在maven的配置文件里面去配置多环境

开发环境叫dev

生产环境叫pro

标记的是yml里面的变量

<!--    配置多环境--><profiles><profile><id>env_dev</id><properties><profile.active>dev</profile.active></properties>
<!--            设置默认启动--><activation><activeByDefault>true</activeByDefault></activation></profile><profile><id>env_pro</id><properties><profile.active>pro</profile.active></properties></profile></profiles>

直接在yml文件里面去读

spring:profiles:active: @profile.active@group:"dev": devDB,devMVC"pro": proDB,proMVC

之后直接打包

package

沿用了maven的设置

这样我们就能实现maven配置

当我们移动这个标签后打包后

配置就是pro 沿用了maven的配置 完成了统一

小结

在maven我们做的这些坐标不是我们拿来用的

而是给boot用的

boot赋值直接拿来用的

通过@符号直接引用这个变量

这里有一个小bug

我们启动springboot

是dev

修改后重启

还是dev

这是idea的一个bug

我们在实际生产过程中会遇到这种问题

这是因为idea缓存的问题 clean都没有用

我们要compile 手工编译 重新加载pom.XML里面的属性

这样就会解决这些bug

小结

我们以后用Linux通过git打包就不会出现这个bug

这就是一个idea的bug

而且maven的compile生命周期也很少有人用