1，发版的质量
（1）一套环境多需求的合入导致只要其中一个需求存在问题，都可能重新发版
（2）多套环境，我们将需求按照产线划分（如跨产线需求可以分别提交）需求互相之间的影响将大大降低，提升发版质量
2，发版的频率和效率
（1）一套环境，合入需求太多，导致任何一个需求修改都得发版，发版频率太高，而且还要等其他需求是否有同样的发版要求，时间上效率大大降低。
（2）多套环境，因产线需求相对集中、测试人员相对固定，发版按照产线自身需求进行，不需要考虑其他需求是否有提测需要，产线自身发版频率降低，效率提高（针对单一点可以迅速发版）
3，提高代码review参与团队的专业性
（1）一套环境代码review涉及团队过大，人员过多，评审时间太长，存在走流程的问题
（2）多套环境下提测前代码review，将对应产线开发、测试和产品是固定的，review过程中更加专业
4，集成测试前置
（1）一套环境因为提测需求多，有些需求测试完毕还要等其他需求测试情况，最后一周前准入
（2）多套环境因为产线需求相对独立，测试完成时间会提前，这样及时合入主线，随时集成测试，减轻了测试压力
5，多需求之间的相互影响
（1）一套环境下（当前副线）要求研发是合并完后执行自测确认的，由于需求量大，涉及人员技术能力不一致，存在相互影响而打回
（2）多套环境下（多个副线）按照产线划分环境，产线外需求相互影响很小，产线内需求影响范围小，相对开发人员和负责人更能把控质量，对研发是合并完后执行自测确认更加精准
6，维护成本考虑
（1）一套环境维护成本肯定低，但不满足部门越来越多的开发工作，n套前端对 n-m 套后端已经是目前不可避免的问题
（2）多套环境维护成本相对高，但对于web来说维护成本是一致的：比如开发环境，只有一套，web端开发模式是本地联调。测试环境多套，但也只是测试在用（自动化部署耗时不不多），现有测试环境已经有5套以上，并没明显感觉维护压力。