一、背景
互联网公司要求快速迭代，所以一般会是多个项目同时在并行开发，另外稍微大点公司基本上是微服务的架构，这样就带来一个问题，测试环境如何搭建？
1、多套开发、测试环境
即一个需求需要测试就是一套环境，好处是相互隔离，缺点是成本太高，这里的成本有以下几方面：机器成本和维护成本，机器成本说好，维护成本主要是指新的版本上线后其它环境如何及时更新，像添加数据库字段、MQ维护队列等都是些很需求，如果没有一套很好的机制则这套环境没过多久就无法用了；
2、一套开发环境、一套测试环境
一套开发环境给开发自测用，另外一套测试环境给所有开发用。
这里的优点是显而易见的，维护成本低。
缺点是多人同时开发一个工程如何处理，这就需要一些规范或者约定了。
因为我们公司用的就是第2种办法，所以简单的说下这种场景遇到的具体问题和解决思路。
二、具体问题及解决思路
这里遇到的问题的前提是多人同时开发同一个工程，如果不存在这个问题就不会这些问题，问题大概分几类：
代码合并规范，即如果多人同时开发一个工程，提测的时候如何合代码；
版本号规范，每次修改工程是否要升级版本号；
打包规范，和上面代码合并有些关联，即什么时候deploy代码到版本库里；
整个流程大概如下：拉取feature分支——》合并到dev分支 ——》将feature分支合并到master分支。
1、代码合并规范
提测时处理
多人并行开发同一个项目要提测时按约定同时合并到一个分支就行了，如dev分支，这个根据自己情况约定，下面以dev分支来讲解；
上线时处理
上线时只能将自己分支的代码合到master，而不能将dev分支合到master；
2、版本号
Maven通过groupId和artifactid来唯一标识每一个项目，项目内部如果有变动可以通过版本号来区别，对于上面的情况每次升级是改版本号还是不改版本号呢？
不升级版本号
这个最简单了，合代码的时候也不用处理版本号的问题；
但这样会带来另外一个问题，可能会把其他人未上线的内容带上去，还有可能带来兼容问题，像一些序列化协议约定了字段在整个流的顺序，这个时候要特别注意。
升级版本号
开发的时候简单，合代码的时候就比较痛苦，要以最新的版本号为准，还有依赖处理，不同分支可能依赖的其它库的版本号不一样，所以要尽量做到向下兼容。
我们实际用的是两者的结合，即兼容的小版本不升级版本号，其它则升级版本号，不兼容主要是以下场景：某些重要的POJO增加新字段，业务流程有大的变化等；
3、Deploy规范
按前面讲的，那Deploy是在feature分支还是dev分支？
如何升级了版本号，即每个分支的版本号不一样则需要在feature分支deploy然后合到dev分支部署测试；
没升级版本号的话可在统一在dev分支上deploy；
但不管是哪一种情况上线前都要在自己的分支上再deploy下，保证其它依赖这个项目拉取的是最新的jar包；
三、写在最后
其实上面2种方案都不是最优方案，就像微服务解决的一个问题就是避免多人在同一分支合代码而容易出错的问题，如何做到能隔离又成本低呢，业界有做逻辑隔离的方案，即同一组机器打标签，让不同的流量通过不同的标签打到不同的分组，这需要从网关和RPC框架的支持，这里就不详述了。
