多环境开发(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: dev
group:
"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生命周期也很少有人用