我们有Dev，QA pre_prod（阶段）和Prod（Trunk）分支。
这就是我们的流程如何运作，请帮助改进使用TFS来利用CI和CD功能的过程..
开发人员更改按计划合并到QA分支，表示冲刺结束。然后从质量保证部门发布。如果发现任何缺陷，QA团队会进行测试，然后在QA分支中完成错误修复，然后与Dev分支合并。 如果QA完成，则QA分支与pre-Prod合并，接受测试由客户完成，然后合并到prod分支并发布给客户。
如果出现生产错误，则在pre-prod分支中进行热修复 - ＆gt;发布用于验收测试（接受QA得到通知的接受env） - >所有好的然后合并到prod分支并发布到客户端。 hot fix未合并到QA，因为它可能会添加其他QA正在进行的签入。因为热修复需要立即修复它直接通过Acceptane测试QA也可以测试..如果所有好的然后合并到QA分支。 缺点： 1.必须进行所有开发以构建质量保证。所以质量保证是空闲的。没有CI。 2.另一个团队合并分支机构。发布它，如果错误再次合并它。资源不是免费的......
我们如何实施TFS CI＆amp; CD功能在这里？
CI更好地适用于一种分支模式，其中签入将触发构建然后QA将测试和批准然后促进生产。但是如果QA拒绝，那么dev必须修复，因为它是单分支，它将与正在进行的每日签入合并，如果在QA中触发更多错误，则此循环将一直重复并且功能无法提升为prod
第二种解决方案可能是建立分支机构特定的CI＆amp; CD作为更改在单个分支中完成。但是在这里我们无法利用CD功能....因为环境之间没有联系......
第三个问题是QA需要一个稳定的环境来测试所有任务。如果在新的部署中通过CD添加，那么QA测试将受到阻碍。
请帮助......如果需要更改流程，请提供您的想法......