1

我在本地使用 TFS 2013。我在构建机器上配置了四个构建代理。几个构建定义编译 ASP .NET 网站。我配置了 msbuild 参数以将 IIS 应用程序部署到集成服务器，该服务器位于 Rackspace 中。

默认情况下，webdeploy 通过比较文件日期进行差异部署。在我的情况下，这是一个很大的优势，因为将文件从我们的网络复制到 Rackspace 需要相当长的时间。现在，为了保留文件日期，构建代理必须编译相同的基本源代码集。在每次构建时，只有差异源代码会产生一个新的 DLL，从而最大限度地减少部署的文件数量。

所有这些都可以正常工作，但需要注意的是：必须将给定的构建定义分配给构建代理（通过代理名称或标签）。问题是当分配给同一代理的所有构建都排队时，我会产生很多意外情况。他们排队等候，直到之前的构建完成。

在理想的世界中，任何代理都应该能够处理任何构建，但是无论代理如何，正在编译的源代码都必须相同。

我尝试将所有代理的工作文件夹更改为指向同一位置，但由于两个代理无法映射到同一文件夹，因此出现错误。我猜每个代理都有一个工作区。

有任何想法吗？

4

2 回答 2

2

最后我找到了一种方法来做到这一点。以下是您需要做的所有更改：

  • 默认情况下，每个代理的工作文件夹是 $(SystemDrive)\Builds\$(BuildAgentId)\$(BuildDefinitionPath)。这意味着每个 BuildAgentId 都有一个工作文件夹。我更改了它，以便所有代理共享同一个文件夹：$(SystemDrive)\Builds\WorkingFolder\$(BuildDefinitionPath)
  • 默认情况下，工作流在运行时创建一个看起来像“[BuildDefinitionId] [AgentId] [MachineName]”的工作区。因为所有代理共享同一个工作文件夹，所以尝试创建每个单独的工作区时会出错。解决方案在构建定义中：编辑 xaml 并查找名为“从 Team Foundation 版本控制获取源”的活动。有一个名为 WrokspaceName 的属性。由于我希望每个构建定义都有一个工作区，因此我将该属性设置为 BuildDetail.BuildDefinition.Name。
  • 保存您的自定义构建模板并创建使用它的构建。
  • 确保选项“1. TF VersionControl/1. Clean workspace”设置为 False。否则构建将清除每个构建上的所有源代码。
  • 确保选项“2. Build/3. Clean build”设置为 false。否则构建将清除每个构建的输出二进制文件。

使用此设置，您可以在任何代理上排队相同的构建，并且所有代理都将指向相同的源代码和 bin 输出。当源代码更改时，仅重新编译受影响的二进制文件。我在模板中有一个自定义步骤，使用 msdeploy.exe 将输出文件部署到 IIS 和我们 webfarm 中的所有服务器。现在我的构建+部署需要一两分钟，因为只有在构建期间更改的 dll 或内容会同步到服务器。

于 2013-12-18T03:14:36.753 回答
1

您不能在同一个文件夹中运行两个构建代理。构建代理的重点是并行运行多个构建，通常在不同的 PC 上。如果您尝试在相同的源代码上运行它们，那么 (a) 毫无意义，因为完全相同源的两个构建应该产生相同的结果，并且 (b) 它们几乎肯定会相互绊倒并导致构建失败或产生意想不到的结果。

如果您希望能够构建并部署一系列版本的代码库，那么有两种选择：

  • 如果您将多个构建排队，那么最后一个将“获胜”，因此中间构建没有真正的价值。因此，如果您在第一次构建完成之前签入新代码，您不妨停止活动构建并开始新的构建。您应该问自己为什么构建如此缓慢，或者为什么您如此频繁地检查更改以至于这是必要的。

  • 如果每个构建都会对部署的结果产生增量更新，那么您需要将构建的输出传递给某个部署代理，该代理能够将其与部署的版本进行比较并仅发送要部署的更改。如果有好处的话，可以设置它来收集来自多个构建代理的结果。

  • 但是我想知道您的构建是否可能很慢，因为您每次都在进行完整构建（它会清理构建文件夹，获取所有源代码并进行完全重建），而您想要的是增量构建（获取最新的更改，仅编译受影响的内容，并快速完成）。也许您应该研究使您的构建增量。

于 2013-11-03T17:20:46.437 回答