问题:

现在团队里面,有两个用户故事1,2 , 由两个团队A,B在分别进行开发;故事1先完成进入测试, 故事2即将完成,也要提测,但是测试环境只有一套,如果把故事2发布到测试环境肯定要影响故事1的测试,  但是又没有多余的机器来部署测试环境。这种情况下,有好的方案解决吗?  而且很有可能 ,用户故事1,2,3,4,5 都先后提测,这样会需要很多测试环境,但没有那么多的测试资源。

于是乎,各种想法喷薄而出:

  1. 虚拟机可以吗?
  2. 12345不需要一起集成测试吗?
  3. 故事12345打算什么时候merge?
  4. 虚拟机是一个解决方案,同时要看测试成本和时间。
  5. 试试容器,要不然为啥容器现在这么火,构建一次就可以部署到一个容器上,独立测试。解决方案就是容器,能用容器是最好。
  6. 一般我们是在一个周期内同时集成测试
  7. 为什么要那么多测试环境呢?集成在一起不行吗?早集成、早构建、早测试
  8. 考虑特性开关?通过开关屏蔽不同的功能?
  9. 瓶颈是测试资源,标准解锁办法就是扩大瓶颈产能。法一:扩大现有测试资源利用比如虚拟化技术;法二:找更多资源,比如买新机器,或者干脆把开发机临时切过来当作测试资源;法三:改变测试方法,降低对测试资源的占用,比如有些测试是否干脆用单元测试替换掉,本地就跑了,只把必要的集成或系统测试用测试机统一跑。法四:改变流程,或者有些功能根本不需要测了,这样测试资源一下大解放。法五….. 思路很多,根据实践情况选择合适的办法就好了。
  10. 拉故事分支,测试环境按时间分配给不同的故事。测试通过分支的合并到主干,合并完了还得再测。
  11. 标准瓶颈处理方法首先不是扩大瓶颈产能,而是挖尽产能,也就是 5步法。瓶颈产能那么容易扩大也就不叫瓶颈了。
  12. 提测和测试环境意味着测试工作,建议改名为验证。貌似离ci还差距很远啊。频繁集成做的太少,所以在集成时需要做相互隔离以避免干扰。典型的分支开发,主干开发就没有这个问题。分支开发,组件开发,属于耗资源人力成本高挑战低成长少的模式,短期看起来最容易,但从长期来看,团队能力很快就会到极限。
  13. 你的1-2-3    几个用户故事需要一次发布吗?两个团队开发,开发环节是两套吗? 如果是,就是分支开发,组件化团队,后面问题还会有很多,最后需要集成在一起发布完整功能的时候需要集成测试,会问题多多。建议早集成,主干开发

真是脑洞大开。

归纳起来,就是优先采用“主干开发”。其次是,早集成、早测试。然后可以采用各种虚拟机、容器等分散开发、各自测试“挖潜能”的办法。