Dropping build output to source control in TFS11

author Richard Fennell calendar Mar 13, 2012 · 2 min read · Uncategorised  ·
Share on: linkedin copy

One of the nice new feature of TFS11 is that you get a third option for what to do with your build output

  • Don’t copy output anywhere – good for CI builds that nobody will ever consume, just used to run tests
  • Drop to a UNC share e.g. \server1drops – the default and used 9 times out 10
  • The new one - drop to source control e.g. $/myproject/drops.

The advantage of this new third option is your build agents can place the files they create in a location that can be accessed by any TFS client i.e. in the source control repository. A user no longer needs to be on a VPN or corporate LAN to be able to see a UNC share.

But remember, just because the builds are in source control does not mean that the build don’t still follow the normal build retention policies, so they will not accumulate forever, unless you want them to.

Now some teams will have good reasons as to why the don’t want builds going into source control. Deployments to a NuGet server and the like will be a far better system for them. This is still all possible, it is just down to build process template customisation. You have not lost any options, just gained another one out the box

But what about building Java via Ant or Maven within TFS using the Build Extensions? Well at this time the process template used to create this type of build from within Eclipse has not caught up with this new feature. However if you really want it you can do the following

  1. Create a TFS build in Eclipse that drops to a UNC share

  2. Open the build definition in VS11

  3. Edit the drops location to point to a location in source control and save the build

    image

  4. When you trigger a new build and you should get you drops in source control. Note in the confirmation dialog you can see the source control based path but you can’t edit it (if you try you get an invalid path error)

    image