Build TFS 2015构建：是否可以在存储库映射中使用变量？

在TFS 2015上创建vNext构建时，可以定义变量，然后在构建步骤中使用，也可以在构建运行的脚本中用作环境变量

我正在处理的构建运行从映射位置提取文件的脚本，因此，如果我可以定义一个变量并在映射中使用它，那就太好了，例如，如果我在构建的项目中更新引用，我可以简单地用新位置更新变量，让存储库映射和脚本都正确地从新位置提取，而无需在多个位置进行更改

我试着通过如下设置变量和映射来实现这一点，

---

但当您试图保存生成时，会产生一个错误，抱怨映射中有两个“$”字符。有没有办法做到这一点，或者说目前还不可能做到这一点？

这是不可能的。正如错误消息所提到的：映射中有两个“$”字符。这意味着应用程序的路径不应因版本而异

存储库页面上的映射用于指定源代码管理 包含需要在生成中生成的项目的文件夹 定义。您可以通过单击省略号（…）按钮进行设置， 但是，不能在映射路径中包含变量

---

还有一个类似的问题：

这也让我有好一阵子不舒服了

对于初学者，有一个uservoice请求使用此功能。您可以在此处添加投票和输入，以使Microsoft允许此功能：

第二，我们已经开发了一种变通方法，使我们大部分时间都能做到这一点。它并不完美，但如果您对权衡感到满意，或者能够解决不足之处，它可能会对您有用

首先关闭构建的“标签源”选项，并将服务器路径字段映射到基本构建。您需要向生成定义中添加一个自定义变量，以告知生成实例要从哪个TFS位置提取。例如，我们有一个基础项目，然后从该项目中有多个分支，因此我们的源代码的结构如下

$\Team Project\Project1
$\Team Project\Project1Branch1
$\Team Project\Project1Branch2
$\Team Project\Project1Branch3

我们创建了一个名为“Branch”的变量，可以设置为“Branch1”、“Branch2”等等

当我们想要构建基本项目时，我们在启动构建时将Branch变量留空。对于分支生成，我们将其设置为要生成的分支的名称

然后我们的构建步骤如下所示

$\Team Project\Project1
$\Team Project\Project1Branch1
$\Team Project\Project1Branch2
$\Team Project\Project1Branch3

• 将工作区文件夹重新映射到分支文件夹
• 获取指定分支的文件-我们必须在 重新映射我们的工作区
• 在指定的分支中编译源代码
• 从指定的分支发布生成构件
• 手动标记指定分支的代码

重新映射任务运行该命令

tf workfold "$/Team Project/Project1$(Branch)" "$(build.sourcesDirectory)\$(Build.DefinitionName)$(Branch)"

手动获取任务运行以下命令

get /recursive /noprompt "$/Team Project/Project1$(Branch)"

tf label "$(build.buildNumber)" "$/Team Project/Project1$(Branch)" /recursive

生成使用Branch变量指向指定分支的解决方案文件的正确位置

$(build.sourcesDirectory)\$(Build.DefinitionName)$(Branch)\SolutionFile.sln

“发布工件”任务在“内容”字段和“路径”字段中使用分支变量 目录中的示例

**\$(Build.DefinitionName)$(Branch)\bin

标签代码任务使用以下命令

get /recursive /noprompt "$/Team Project/Project1$(Branch)"

tf label "$(build.buildNumber)" "$/Team Project/Project1$(Branch)" /recursive

此设置的缺点是，由于服务器路径字段始终设置为主位置，因此无法将相关更改和工作项捕获到附属分支。如果您总是在启动准备投入生产的构建之前将分支合并到主位置，那么这可能不是问题。您能做些什么来弥补这一点实际上取决于您的用例

---

通过一些调整，如果需要，您也可以使用相同的格式指定完整路径。

您在函数上是正确的，但在路径不应随构建而更改的断言上是错误的。在开发过程中通常会有多个环境，构建这些环境的过程在理想情况下应该是相同的。通过手动输入这些独立的子树/分支，这将成为一个故障点，并且还会使用执行完全相同操作的重复条目将构建环境弄得一团糟。这相当于为客户地址之类的内容将重复数据输入数据库，这是一个严重的设计缺陷。您在VST的限制范围内以优雅的方式修复了该问题。但是，使用这种方法存在性能问题。我们有相当多的发布分支，在构建之前必须检查所有内容，我认为这会非常缓慢。谢谢你的夸奖。当你说“在构建之前必须检查所有内容”时，我不确定你指的是什么。在这种情况下，检查文件不应该是必要的（虽然我们的构建有一个签出操作，但对于这个问题它们不是必需的，我只是忽略了删除对它们的引用，现在看不到它们）.在仔细考虑了您的评论之后，我认为您指的是每个分支的“获取”操作。如果是这样，不要担心——上面的解决方案只从主位置（服务器路径字段中的路径）和“branch”变量指定的特定分支“获取”源。因此，尽管它确实“获得”了一个不必要的分支，除非它是一个特定的主构建，但它只是一个——它不会“获得”解决方案中的每个分支。