目录
关于公司项目的配置文件,我一共改过两次比较大的改动,从实际意义上解决运维发版部署问题,下面记录一下第一次改动场景原因和效果。
问题场景原因
项目是小程序后台,有一个web管理前端界面,后台共用,只服务一个小程序平台,领导安排新部署一个小程序后台,
需要的东西就是:
1、新平台中小程序相关信息整理好,更新到一个新的properties文件中
2、准备部署的服务器和创建对应的数据库
3、安装其它中间件
以上三项是必须做的,下面打包到部署就有两种可行办法了,一是从新打包,二是拷贝已部署的解压包,直接替换配置文件,修改引用的文件名,运维倾向于第二种,实际也是这么做的。项目配置文件路径固定,配置项固定,可以写脚本一键替换(我当时这样想的不可行否),实际修改是看到了引用配置文件里的地方:
<context:property-placeholder location="classpath:filters/prod.properties" />
<import resource="classpath:spring/applicationContext-service.xml" />
...
拷贝项目部署包之后,还要做的修改:
4、修改这里prod改成新文件名,新文件里就要部署的平台配置
5、因为编码加载问题,还要更改另外一个专门配置小程序相关配置的文件,生产上fdfs配置共用就没修改
以上是起初部署新小程序后台过程,比较繁琐,现在我准备要简化一下,整理好新配置文件后,就是只修改引用文件名prod到新配置文件名new,就实现部署
改动过程一
项目本身maven管理,有三套配置文件,dev,test。prod,项目打包时指定P环境参数实现指定配置生效,项目一般都是这样,我们项目还有两点特殊的地方就是对fdfs连接管理和微信小程序相关配置的加载,这两个东西的配置都是另一个单独的配置文件保存的,它们的加载方式也是脱离了spring的管理:
1、fdfs加载初始化是用ClientGlobal.initByProperties方法,这个方法参数直接就是配置文件路径,要用${}或@value方式还真行不通
2、微信小程序相关配置还是用java.util.Properties的load方法加载之后设置到工具类静态变量
不要问我为啥这样弄,我也搞不懂搭建时的人想法,于是我开始了第一波前半段改造,自然是消除这两个不分环境的配置文件,放到唯一的配置文件中,实现spring统一管理加载配置,这改造过程坑很多,慎重点还是没错,改好了是应该的没人说,改不好那就真的不好了,这工作也不是领导安排要做的,不做也没人说什么,但这配置不合理影响每次开发还是感觉不爽的算是主动请缨吧,既然决定做了就有耐心,细心把它做好。关于spring管理初始化fdfs的配置,我后面更新一个文章连接放这里。
改造到这里,只有一个配置文件需要管理和加载,已经实现了一条maven命令打不同环境的部署包。
改动过程二
现在再说配置文件打包后切换,这种配置文件在打包之后,xml文件中引用${xxx}写法会替换成具体的值,也就是说打包之后没有变量了,上面那个引用prod配置文件的地方修改已经没有用了,所以这里引用了一个中间文件,命名为config.properties,里面配置:
temp.key1=${key1}
temp.key2=${key2}
temp.key3=${key2}
...
然后把所有的xml文件引用的${xxx}都改成${temp.xxx}
这样打包出来的效果xml文件里替换之后还会是变量,就是${temp.xxx},但是config.properties这个文件里不能替换,这里需要配置pom.xml里的resource:
<resource>
<directory>src/main/resources</directory>
<includes>
<include>spring/application-config.xml</include>
<include>*/.properties</include>
</includes>
<filtering>true</filtering>
</resource>
<resource>
<directory>src/main/resources</directory>
<excludes>
<exclude>spring/application-config.xml</exclude>
<exclude>*/.properties</exclude>
</excludes>
<filtering>false</filtering>
</resource>
这第一个resouce配置了需要过滤的文件,这些文件打包后会替换成具体值
第二个resource配置不需要过滤的文件,用的exclude,就是排除这些文件以外的文件,上面说的中间文件config.properties就属于这里的
最终效果
以上配置完成后,以后再部署新后台,就可以只修改一个文件名实现。下面更新第二次配置文件改造,与apollo对接。