我使用的处所TFS 2013。 我有一个构建机器上配置了四个生成代理。 几个生成定义编译ASP .NET网站。 我配置的MSBuild参数部署IIS应用程序集成服务器，它坐落在那里的Rackspace公司。
默认情况下webdeploy通过比较文件日期不差部署。 在我而言，这是一个大利好，因为从我们的网络将文件复制到Rackspace公司需要相当长一段时间。 现在，为了保存文件日期生成代理已编译相同的基本组源代码。 在每一个构建仅差速源代码产生一个新的DLL，最大限度地减少部署的文件的数量。
所有这一切工作正常，有一点需要注意：在给定生成定义有被分配到一个生成代理（由代理人姓名或标签）。 问题是我创造了很多应急的时候都建立分配到同一个代理排队等候。 他们排队等候，直到前构建完成。
在一个理想的世界任何代理应该能够采取任何构建的照顾，但被编译的源代码必须是相同的，无论剂。
我试图改变所有代理的工作文件夹指向同一个位置，但我得到一个错误，因为两个代理不能映射到同一个文件夹中。 我想有每个代理一个工作区。
有任何想法吗？
最后，我找到了一种方法来做到这一点。 下面是你需要做的所有更改：
有了这个设置，你可以排队相同的构建上安装任何代理，和所有的人都将指向相同的源代码和仓输出。 当源代码只改变了受影响的二进制文件重新编译。 我有在部署文件输出到IIS，在我们webfarm所有服务器，使用msdeploy.exe模板的自定义的步骤。 现在我建立+部署需要一两分钟，因为只有在构建过程中更改的DLL或内容同步到服务器。
你不能在同一个文件夹中运行两个生成代理。 生成代理的一点是要运行多个构建并联，通常在单独的PC。 如果你尝试在相同的源代码运行它们，然后（一）这是毫无意义的两个构建完全相同的源应该产生相同的结果，和（b）他们几乎肯定会超过对方绊倒，并导致建立以失败或产生意外的结果。
如果您希望能够建立，然后部署了一系列的代码库的版本，则有两种选择：
如果你排队多个版本，那么最后一个将“赢”，所以中间版本是没有实际价值的。 所以，如果你在新的代码检查你的第一个构建完成之前，您不妨停止活动的构建和启动一个新的。 你应该问自己，为什么构建是如此缓慢，或者为什么要在变化如此频繁，这是必要的检查。
如果每个版本产生的增量更新到部署的结果，那么你需要通过你的构建到能够diff的它反对部署的版本，并部署仅改变发送一些部署代理的输出。 这可以被设置为收集来自多个生成代理的结果，如果这将是有益的。
但我不知道也许你的版本是缓慢的，因为你正在做的每一次完整的构建（用于清洁生成文件夹，得到所有的来源，并完全重建），当你需要的是增量构建（其中获取最新变化，只有正迅速受到影响，并完成编译）。 也许你应该调查使您的构建增量。
