0

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

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

我们的构建服务器还托管删除的文件，因此在复制大量文件时，强制文件复制操作通过网络共享似乎会引入很多延迟时间。我想覆盖此功能，以便我可以指定放置位置的本地目录，但我不知道如何。

4

3 回答 3

0

我没有使用 2008 版本，只有 2005 版本，但您似乎可以手动执行此操作。将 SkipDropBuild 属性设置为 true。然后使用 Team Build 内置的 Copy 命令在 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>
于 2008-12-03T22:06:20.577 回答
0

实际的 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 目标文件，所以我不能确切地说那是什么所以当我回到我的办公桌并相应地编辑这个答案时，我会查找它。

也就是说，这样做有很多风险。

  1. 您必须确保所有文件路径排列正确，否则查看构建日志或使用测试结果填充 TFS 仓库等操作可能会停止工作
  2. 您将硬编码构建和放置位置以始终存在于同一台机器上。如果有人试图在另一台机器上构建您的 TFSBuild.proj 文件，那么事情将不会像他们预期的那样工作
  3. 如果有人在构建定义中编辑放置位置属性，那么他们必须知道在 TFSBuild.proj 文件中进行相应的编辑

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

于 2009-08-07T22:43:44.370 回答
0

我找到了一个更简单的解决方案，那就是在 Release 文件夹上移动文件系统。由于放置位置实际上位于同一个物理驱动器上，我可以接受。我已将此添加到 TFSBuild.proj 文件中：

<Target Name="CoreDropBuild"
        Condition=" '$(SkipDropBuild)'!='true' and '$(IsDesktopBuild)'!='true' "
        DependsOnTargets="$(CoreDropBuildDependsOn)" >
    <Exec Command="move $(BinariesRoot)\Release d:\BuildOutput\$(BuildNumber)\Release"/>
</Target>
于 2008-12-09T13:12:00.230 回答