背景:
就目前开发测试正式环境使用同一套代码的方式,存在多个需求同时开发时,部分需求需要紧急发布正式环境,而另外的需求却还未经过测试验证,导致发布后出现部分业务无法正常办理问题。就此情况,规划分两套代码开发测试(开发和测试使用同一套代码和数据库,统称开发测试)与正式,进行svn+maven的分支管理。
1,创建一个versionsControllerDemo(类似于平台的site和api),和一个versionsControllerService(类似于平台的service)。
2,给versionsControllerDemo与versionsControllerService创建一个开发测试分支。项目如下,左边是正式,右边是开发测试分支。
3,测试案例01:
1)同时开发多个需求如q1,q2。q1测试未通过,不能发布正式;q2测试通过,并需要在正式环境发布。
q1:service提供一个打印hello cmbl的接口。
q2:service提供一个计算数字相加的接口。
备注:完成代码开发后需将代码提交到svn,并提交到私服(注意版本号的控制,具体可参见后面第5点)。
2)接口编写完成,前端实现调用。versionsControllerDemo中完成前端页面和接口的调用。
3)q2已经过测试(此时q1代码已经存在,但是未经过测试)。q2准备在正式环境发布。
4)将经过验证后的q2合并到正式环境,并发布。
合并versionsControllerService
合并versionsControllerDemo
4)查看合并后的代码(并不存在未经测试的q1),没有问题可以发布。
前端
以上是基于svn的多个需求同时开发,选择测试通过之后的需求发布正式。
5,基于svn+maven+nexus+jenkins的版本控制和打包发布。
但是目前我们的项目是基于maven来实现自动化构建和打包的。打包时所使用的service并不在本地,而是根据maven配置将service提交到私服,再根据配置来完成自动化打包的(比如选择测试,则会根据测试配置来打包,同样选择正式就会根据正式的配置来打包,此部分目前已使用jenkins来做自动实现打包发布了,开发人员可以忽略)。而和开发人员有直接关系的是service的版本号配置。
其中<version>0.0.2-SNAPSHOT</version> 0.0.2代表版本号,建议每完成一个需求将此版本升1,如 0.0.3。第一位数是提供服务或产品的代数,第二位为大版本号,第三为小版本号,最后的SNAPSHOT表示此版本为快照版,可以理解为就是我们的测试代码(开发和测试共用同一个版本库)。在升级到正式环境后需要取消SNAPSHOT标识,标记为正式版(稳定版)。
如前面所开发完成的需求q2,将原版本0.0.1-SNAPSHOT修改为0.0.2-SNAPSHOT并提交到私服(执行deploy)。结果如下,可以在私服中看到提交后的service的jar包。
6,发布正式,将需求q2代码升级为正式稳定版,此步与测试案例01中的3)同时完成。具体步骤与上类似。
将开发测试中已经完成的需求q2合并到正式环境后,同时将service中的版本号由原来的<version>0.0.1</version>修改为<version>0.0.2</version>。提交到私服后,即可在Jenkins中完成自动发布。
总结:
关键步骤:
1,在开发测试环境完成开发,将我完成后的需求提交到svn并提交到私服,同时注意版本号的控制(一般只需要在原来的版本上加1就好)。
2,合并到正式环境。选择在测试环境已经经过测试的需求合并到正式环境,将代码提交到svn,同时提交到私服(一般只需要在原来的版本上加1就好)。
3,在jenkins上点击发布就好。