从我迄今所看到的，使用发布管理的常用方法是使用下面的版本路径：MS发布管理和补丁部署
Dev -> Test -> Production
比方说，我有：
版本甲在生产中，在测试
版本B（=版本A +新功能）
是否有一种简单的方法来为版本A部署"Patch"（即，版本A的快速修复，没有版本B的新功能）？
这是一个常见的问题，我没有看到有关该特定问题的任何主题。这通常是通过在tfs（或git）上分支代码完成的，但分支与发布管理理念不完全兼容。
...或者我错过了什么？
您可以通过“开关”（功能切换）来隐藏/禁用版本B的新功能，然后您只需启用它们即可。更多详情here。
我想说这个问题更多的是源代码管理和构建系统，而不是发布管理。虽然，就您而言，MS Release Management的路径不支持将修补程序应用于该路径中的一个Stage。出于这个原因，我们管理多个版本和发布路径。一些经历了整个开发 - >质量保证 - >生产，其他人直接进入每个阶段。这确实意味着当我们对任何版本进行更改时，我们必须多次进行相同的更改。
尽管分支解决方案最近变得不太流行，但这是我的团队倾向于同时保留开发和发布分支的事情。我们向我们的发布分支进行代码升级，并仅从该分支构建我们的发布。
我们需要做的任何修补程序或修补程序，我们要么直接提交到发行版分支（以后再反向集成回Dev分支），要么推进单个更改集转发。
更多TFS分支策略：http://vsarbranchingguide.codeplex.com/
如果你不想去的分支，另一种选择是滚动回你的代码的最后已知的释放点，代码的补丁，搁置该代码，然后打造并释放搁架。
最近在发布管理中发布的新功能允许这种自定义行为。
现在，你必须按顺序部署的能力，并行，或以任何其它用户指定的顺序（您也可以手动部署）
可以触发与修补版本A中的新版本（添加关于补丁的一些描述稍后确定），不需要部署条件，然后可以手动部署到任何您想要的环境。
去了此链接以查询更多 - https://blogs.msdn.microsoft.com/visualstudioalm/2016/01/07/vsts-release-management-plans-for-2016-h1/
这是不一样的东西： A +补丁 是不一样的 A + B（切换关闭）+补丁。 可能有副作用等 –