Question

在Team Build 2008中，不再在.proj文件中指定构建的删除位置，而是存储在数据库中并在GUI工具中维护。

GUI工具仅接受网络路径作为放置位置（即\\ server \ share），并且不接受本地路径。

我们的构建服务器还托管已删除的文件，因此强制文件复制操作通过网络共享似乎会在复制大量文件时引入大量延迟时间。我想覆盖这个功能，以便我可以为drop location指定一个本地目录，但我无法弄清楚如何。

Answer 1

我没有使用2008版本只有2005版本，但似乎你可以手动完成。将SkipDropBuild属性设置为true。然后使用Team Build中内置的“复制”命令在BeforeDropBuild事件中手动复制所有二进制文件。

这样的事情：

<SourceDir>$(SolutionRoot)\..\Binaries\Release</SourceDir>
<SkipDropBuild>true</SkipDropBuild>
<CreateItem Include="$(SourceDir)\**\*.*">
        <Output TaskParameter="Include" ItemName="BuiltBinaries"/>
</CreateItem>
<Target Name ="BeforeDropBuild">
        <Copy SourceFiles="@(BuiltBinaries)" DestinationFiles="@(BuiltBinaries->'C:\droplocation\%(Filename)%(Extension)')"/>
</Target>

Answer 2

我找到了一个更简单的解决方案，那就是在Release文件夹上执行文件系统 move 。由于丢弃位置实际上位于同一个物理驱动器上，我很好。我已将此添加到TFSBuild.proj文件中：

<Target Name="CoreDropBuild"
        Condition=" '$(SkipDropBuild)'!='true' and '$(IsDesktopBuild)'!='true' "
        DependsOnTargets="$(CoreDropBuildDependsOn)" >
    <Exec Command="move $(BinariesRoot)\Release d:\BuildOutput\$(BuildNumber)\Release"/>
</Target>

Answer 3

实际的BuildDropLocation需要在网络共享上可用。发布测试结果时，客户端和TFS应用程序层将使用放置位置。访问构建结果时，客户端和TFS应用程序层机器也需要访问它。作为数据仓库步骤的一部分，TFS应用程序层机器将通过放置位置访问构建结果，以查找要添加到仓库的测试结果文件。

也就是说，假设您的构建服务器是托管您的放置位置共享的同一台机器 - 并且将始终是同一台机器，那么您可以跳过TFSBuild.proj中的放置步骤。一种解决方案可能是Todd和Chad概述的那些解决方案的组合，例如：

<SkipDropBuild>true</SkipDropBuild>
<Target Name ="AfterDropBuild">
        <Exec Command="move $(BinariesRoot)\Release d:\BuildOutput\$(BuildNumber)\Release"/>
</Target>

请注意，您实际上不应该对“Release”部分进行硬编码，但能够从配置属性中获取 - 但是我没有我的TeamBuild目标文件，所以我不能确切地说是什么现在是这样，当我回到我的办公桌并相应地编辑这个答案时，我会查一查。

据说这样做有很多风险。

您必须确保所有文件路径都排列正确，或者查看构建日志或填充测试结果的TFS仓库等内容可能会停止工作
您将构建和删除位置硬编码为始终存在于同一台计算机上。如果有人试图在另一台机器上构建你的TFSBuild.proj文件，那么事情将无法正常工作
如果有人在构建定义中编辑了drop location属性，那么他们必须知道在TFSBuild.proj文件中进行相应的编辑

因此，由于这种方法涉及可维护性问题 - 我绝不会在绝大多数情况下推荐它。值得做一个测试，看看实际节省了多少时间，以确定在您的环境中是否值得进行优化。

我可以覆盖DropLocation目标以避免网络延迟吗？

3 个答案: