svn+maven+nexus+jenkins版本分支控制案例

背景：

就目前开发测试正式环境使用同一套代码的方式，存在多个需求同时开发时，部分需求需要紧急发布正式环境，而另外的需求却还未经过测试验证，导致发布后出现部分业务无法正常办理问题。就此情况，规划分两套代码开发测试（开发和测试使用同一套代码和数据库，统称开发测试）与正式，进行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上点击发布就好。