Can I override DropLocation target to avoid network latency?

Question

In Team Build 2008, the Drop Location for a build is no longer specified in the .proj file, and instead is stored in the database and maintained in the GUI tool.

The GUI tool only accepts a network path as a drop location (i.e. \\server\share) and will not accept a local path.

Our build server also hosts the dropped files, so it seems that forcing a file copy operation to go through the network share introduces a lot of lag time when copying a large number of files. I would like to override this feature so that I can specify a local directory for drop location, but I can't figure out how.

Answer 1

I haven't worked with the 2008 version only the 2005 version, but it seems you could do this manually. Set the SkipDropBuild property to true. Then copy all the binaries manually in the BeforeDropBuild event using the Copy command built into Team Build.

Something like this:

<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

I've found an easier solution, and that is to just do a file system move on the Release folder. Since the drop location actually sits on the same physical drive, I'm ok with that. I've added this to the TFSBuild.proj file:

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

Answer 3

The actual BuildDropLocation needs to be available on a network share. The drop location is used by clients and the TFS Application Tier when you publish test results. It also needs to be accessible to both clients and the TFS Application Tier machine when accessing build results. As part of the datawarehouse step the TFS Application Tier machine will access the build results over the drop location to find the test results files to add to the warehouse.

That said, assuming that your build server is the same machine that is hosting your drop location share - and will always be the same machine then you can skip the drop step from the TFSBuild.proj. One solution would probably be a combination of those outlined by Todd and Chad i.e. something like:

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

Note that you shouldn't actually have to hard-code the "Release" part but be able to get that from the configuration properties - however I don't have my TeamBuild targets file to hand so I cannot say exactly what that is at the moment so I'll look it up when I get back to my desk and edit this answer accordingly.

That said there are quite a few risks involved in doing this.

1. You have to make sure that you have all the file paths lined up exactly right or things like viewing a build log or populating the TFS warehouse with test results might stop working
2. You will have hard-coded your build and drop locations to always exist on the same machine. If someone attempts to build your TFSBuild.proj file on a different machine then things won't work as they expect
3. If someone edits the drop location property in the build definition then they have to know to make a corresponding edit in the TFSBuild.proj file

Therefore because of the maintainability issues involved in this approach - I wouldn't recommend it in the vast majority of cases. It would be worth doing a test and seeing how much time this actually saves to to determine if it is a worthwhile optimization in your circumstances.