我们正在使用 Visual Studio Team Services 。
我们有一个Prod-Branch，它由我们的Prod-Build-Definition构建，并由我们的Prod-Release-Definition部署到我们的测试/集成和生产环境中。
随着每个Prod-Release部署到客户，我们从Prod-Branch创建了一个Prod-Rel-Version-x.x.x分支（如果我们需要一个Hotfix）。
在Sprint期间，我们正在开发Dev-Branch，它由我们的Dev-Build-Definition构建，并由我们的Dev-Release-Definition部署到我们的DEV环境中进行开发人员测试。
在Sprint（或不时）之后，Dev-Branch被合并到Main-Branch，然后合并到Prod-Branch。从那里，它被部署到客户的不同测试阶段。
当存在Hotfix-Case时，我们修复了Prod-Rel-Version-xxx分支上的错误，并希望重用我们现有的Prod-Build-Definition来构建此Hotfix-Version并通过以下方式部署到不同的阶段：现有的Prod-Release-Definition用于测试并使用此版本。
我们如何在这个不同的分支（Prod-Rel-Version-x.x.x分支而不是Prod-Branch）中重用我们的Prod-Build-Definition？
当我查看构建定义时，我想我是可能的，只需编辑从$/NameOfOurApp/Prod到$/NameOfOurApp/Prod-Rel-Version-x.x.x)的服务器路径（存储库＆gt;映射）......应该做的伎俩或不？但是从我读到的内容来看，在服务器映射中不可能使用Build-Variables，所以我无法更改此变量，例如在Queue new Build Dialog中...
完成我的方案的最佳方式是什么？
答案 0 :(得分：5)
执行此操作的唯一方法是创建一个下载所有分支的构建定义。然后在任务中使用变量来选择要构建的版本。这将变得非常混乱（并且很慢）。
相反，克隆构建定义要容易得多。或者，您可以从现有构建定义创建构建定义模板，并使用它来创建新的构建定义。
然而，一个更好，更好的解决方案是不依赖于这么多分支。当你真的需要创建一个修补程序时，你只需要分支，而当你有更多的结果时你只需要阶段分支阶段。通过改进你工作的方式，你将能够摆脱分支，简化所有人的工作。
VSTS和TFS 2018现在支持在工作空间定义中使用变量。