我生待明日,万事成蹉跎

一次较为复杂的maven工程隔离开发和生产环境的处理实践

一。背景
jwell-km-api-client是web工程,依赖了一个jar工程jwell-wms-api。
jwell-wms-api工程里面有一个xml文件配置了一个地址。地址分为测试地址和正式地址。
jwell-km-api-client工程在打包时,要区分测试环境和正式环境。包括其依赖的jwell-wms-api工程里面的地址也要自动区分测试环境和正式环境。

二。处理过程

之前我做过web工程resources下面参数的处理。文章地址是http://blog.csdn.net/qq_37372909/article/details/78522414

如果我在web工程通过上次文章中的方法,只能修改web工程本身resources下面的配置文件,无法修改起依赖的jar工程jwell-wms-api内部xml。
我苦想,web工程与jar工程是通过依赖建立起关系的。如果让web工程2个环境依赖不同的2个jar包,这个问题能解决。但是前提是2个环境的web工程都是同一份源代码,2个jar也是同一份源代码。这个问题该怎么处理呢?我思考了一会。
解决初步思路为让两个不同环境的web工程分别依赖2个不同环境的jar(版本号不同)组件
具体处理过程如下:
修改jwell-wms-api中的xml配置,把写死配置修改为参数。
再修改其pom文件,添加默认的参数配置。
再确认pom修改了自动参数替换,这样3个配置后,开发默认的测试环境就解决了。
但是仅仅做这些是不能解决问题的,就算在jenkins上正式环境的配置设置为正式地址。但是如果测试和正式都要打包,上传maven私库里面的组件就会一会是正式地址,一会是测试地址,会造成web工程依赖错误环境组件的可能。我准备继续改造jwell-wms-api的配置参数,让他上传到私库为2个不同版本的组件,默认版本号为1.0.0的是测试环境,1.0.0-official版本为正式环境地址。再让2个不同环境的jwell-wms-api-client打包任务分别依赖这2个jar组件,就能达到理想效果了。
jwell-wms-api的配置改造为:修改pom中版本定义为动态参数,并配置默认版本号为1.0.0
再把正式环境的配置添加到jenkins服务器上面setting.xml配置文件中profile里面
添加了2个参数,一个是正式环境的地址,一个是正式环境的版本号
再在jenkins上面建立2个环境对应的打包任务。
下面是正式环境的任务配置,该任务运行,就会把参数修改,并发布一个版本号为1.0.0-official的组件到maven私库。
下面是测试环境对应的配置,这样会发布一个版本为1.0.0的组件到maven私库
到这里,一份源代码,2个不同环境配置对应了2个不同的版本号组件准备好了。只需要修改web工程jwell-wms-api-client依赖不同版本的jar工程就好了。
修改jwell-wms-api-client的pom文件,把jwell-wms-api组件依赖的版本号修改为动态参数。并设置默认版本号参数为1.0.0,就是默认依赖的测试环境对应的版本号。
再为2个不同的环境准备参数,修改jenkins服务器setting文件。
测环境参数只配置了地址,版本号已经默认过了,其实测试地址也默认过了,可以不配置的,哈哈哈。
正式环境参数配置了jar工程需要的2个参数和web工程需要的不同版本号1个参数。
再在jenkins建立web工程jwell-wms-api-client的2个环境打包任务。
下面是测试环境的配置,虽然使用的profile是official,但是这组参数其实只是测试服务器需要的配置。
下面是jenkins配置的web工程正式环境对应的任务
这样,任务就完美完成了。
web工程jwell-km-api-client正式环境打包会依赖一个版本号为1.0.0-official的组件。
web工程jwell-km-api-client测试环境打包会依赖一个版本号为1.0.0的组件。
但是2个组件源代码只有一份,都是jwell-km-api。只是发布到了maven私库是2个版本,1.0.0是测试环境版本,1.0.0-official是正式环境版本。

未经允许不得转载:徐宏涛博客 » 一次较为复杂的maven工程隔离开发和生产环境的处理实践

分享到:更多 ()

评论 抢沙发

评论前必须登录!