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