当前公司的研发背景是 先研发出来产品，2周快速迭代，2周 7个工作日用于开发 2个工作日用于测试 1个工作日用于演示，演示并验收完然后上线。
目前只有 开发环境、测试环境、稳定环境、预发布环境、生产环境，共5套环境，系统架构为微服务架构。
开发甲小组 开发环境 开发A模块 功能，发布到测试环境为V3.16.1分支
开发乙小组 开发环境 开发A模块 功能，发布到测试环境为V3.16.2分支
由于 开发甲小组 速度比较快，或者业务简单一些，效率高一些，开发甲小组 已经走到了预发布环境，开发乙小组走到了测试环境；由于2个小组都开发了同1个模块；
开发甲小组先上线了，然后开发乙小组走到预发布环境发现 有8个服务产生冲突；这时就需要 在预发布环境 做一次 不同迭代业务模块的 全业务的流程测试，但是此时已打破了271的2周迭代的研发周期。
这里出现的问题有几个：
1、迭代周期必定延期（被无情扣绩效、扣绩效、扣绩效）
2、不同的小组代码产生了冲突（开发乙小组 把 开发甲小组的代码给覆盖掉了）
3、不同的小组开发相同的业务模块时，会自己重新写一些接口去实现一些功能，产生了大量的代码冗余或接口冗余
4、不同开发小组 不考虑冲突的情况下，陆续上线了，最后随着迭代次数增加，线上没有经过 全业务流程测试的 版本越来越多，最后线上会出现越来越多的的莫名其妙的bug（测试环境都正常，到了生产环境就有了很多的bug）
5、先上线的版本也需要重新发版
产生问题的原因：
1、修改bug或者迭代过程中 多个小组都开发同一个模块业务
2、迭代的进度速度 不一样，产生代码冲突，不同迭代版本的整体业务流程无法测试到
3、测试时间被无情压缩，测试充分性与需求覆盖度无法保证
4、迭代次数过多：业务碎片化增多、代码碎片化增多、测试碎片化增多
前提是不打破721敏捷研发模式（跑火车模式），也不能拆分业务的情况下（几个小组做得同一个产品项目），如何解决 不同小组在 代码合并以及上线后的质量问题？
理想状态：
甲乙小组 各自开发的分支 同时合并到测试环境、合并到稳定环境、合并到预发布环境，在各个业务功能都整合的情况下 测试，但是实际情况无法达到理想状态。
xiezhifei