TFS 2013生成代理共享公共生成文件夹
我正在使用TFS 2013内部部署。我在一台生成机器上配置了四个生成代理。一些构建定义编译ASP.NET网站。我配置了msbuild参数以将IIS应用程序部署到集成服务器，该服务器位于Rackspace中 默认情况下，webdeploy通过比较文件日期进行差异部署。在我的例子中，这是一个很大的优势，因为将文件从我们的网络复制到Rackspace需要相当长的时间。现在，为了保留文件日期，构建代理必须编译相同的基本源代码集。在每个构建中，只有差异源代码生成一个新的DLL，从而最小化部署的文件数量 所有这些都很好，但有一个警告：必须将给定的构建定义分配给构建代理（通过代理名称或标记）。问题是，当分配给同一个代理的所有构建都排队时，我会产生很多意外情况。他们排队等待，直到上一个构建完成 在理想情况下，任何代理都应该能够处理任何构建，但是无论代理是什么，编译的源代码都必须相同 我尝试将所有代理的工作文件夹更改为指向同一位置，但出现错误，因为两个代理无法映射到同一文件夹。我想每个代理都有一个工作区TFS 2013生成代理共享公共生成文件夹,tfs,tfsbuild,Tfs,Tfsbuild,我正在使用TFS 2013内部部署。我在一台生成机器上配置了四个生成代理。一些构建定义编译ASP.NET网站。我配置了msbuild参数以将IIS应用程序部署到集成服务器，该服务器位于Rackspace中 默认情况下，webdeploy通过比较文件日期进行差异部署。在我的例子中，这是一个很大的优势，因为将文件从我们的网络复制到Rackspace需要相当长的时间。现在，为了保留文件日期，构建代理必须编译相同的基本源代码集。在每个构建中，只有差异源代码生成一个新的DLL，从而最小化部署的文件数量 所
有什么想法吗？不能在同一文件夹中运行两个生成代理。构建代理的要点是并行运行多个构建，通常在单独的PC上。如果您尝试在相同的源代码上运行它们，那么（a）这是毫无意义的，因为两个完全相同源的构建应该产生相同的结果，以及（b）它们几乎肯定会互相绊倒，导致构建失败或产生意外结果 如果您希望能够构建并部署一系列代码库版本，那么有两个选项：
- 如果您将多个构建排队，那么最后一个构建将“获胜”，因此中间构建没有实际价值。因此，如果您在第一个构建完成之前签入新代码，那么您也可以停止活动构建并启动一个新的构建。您应该问问自己，为什么构建如此缓慢，或者为什么您如此频繁地签入更改，以至于这是必要的
- 如果每个构建对部署的结果产生增量更新，那么您需要将构建的输出传递给某个部署代理，该代理能够将其与部署的版本区分开来，并且只发送要部署的更改。如果这样做有益的话，可以将其设置为从多个构建代理收集结果
- 但是我想知道，您的构建是否很慢，因为您每次都在进行完整的构建（清理构建文件夹、获取所有源代码并进行完整的重建），而您需要的是增量构建（获取最新的更改、只编译受影响的内容并快速完成）。也许您应该研究如何使构建增量化
- 默认情况下，每个代理的工作文件夹为$（SystemDrive）\Builds\$（BuildAgentId）\$（BuildDefinitionPath）。这意味着每个BuildAgentId有一个工作文件夹。我更改了它，以便所有代理共享相同的文件夹：$（SystemDrive）\Builds\WorkingFolder\$（BuildDefinitionPath）
- 默认情况下，工作流在运行时创建一个类似“[BuildDefinitionId][AgentId][MachineName]”的工作区。由于所有代理共享同一个工作文件夹，因此尝试创建每个单独的工作区时出错。解决方案是在构建定义中：编辑XAML并查找一个名为“Team Foundation版本控制的GET源”的活动。有一个名为WrokspaceName的属性。因为我希望每个构建定义有一个工作区，所以我将该属性设置为BuildDetail.BuildDefinition.Name
- 保存自定义生成模板并创建使用该模板的生成
- 确保选项“1.TF VersionControl/1.Clean workspace”设置为False。否则，构建将删除每个构建上的所有源代码
- 确保选项“2.Build/3.Clean Build”设置为false。否则，构建将清除每个构建上的输出二进制文件
- 我终于找到了一种方法。以下是您需要进行的所有更改：
使用此设置，您可以在任何代理上对相同的构建进行排队，并且所有这些构建都将指向相同的源代码和bin输出。当源代码更改时，只重新编译受影响的二进制文件。我在模板中有一个自定义步骤，使用msdeploy.exe将输出文件部署到IIS，部署到我们webfarm中的所有服务器。现在，我的builds+部署需要一两分钟，因为只有在构建过程中更改的DLL或内容才会同步到服务器。关于bullet 1，我应该澄清，我不希望在多个代理上同时构建相同的构建定义。我使用滚动构建触发器一次只运行一个构建。在这种情况下，特工们不会互相绊倒。对于bullet 2，假设我调用msdeploy.exe作为工作流的一个单独步骤，我想我会遇到同样的问题；datetimes不会在来自不同代理的输出之间匹配，并且它将部署比需要更多的文件。关于bullet 3，我不清理构建文件夹。构建本身非常快。这项耗时的活动是部署的。我认为我不理解你的问题。如果您可以快速构建，但部署很慢，并且部署覆盖了以前的版本，那么这些选项听起来像：杀死中间构建，因为它们无论如何都会被覆盖；检查一下为什么您的部署如此缓慢（您可以升级到服务器的链接吗？您可以压缩部署文件吗？等等）我同意@Jason Williams的观点-不清楚为什么您需要使用多个代理来描述问题。拥有多个代理的目的是并行构建，不过他的选择很好