Build on the Team Foundation Service

Build on the Team Foundation Service

  • Comments 10

Today we are pleased to enable another great capability of Team Foundation Server on the Team Foundation Service Preview, Build. With the introduction of build we are combining the power and flexibility of Team Build with the low friction setup of the Team Foundation Service and continuing our efforts to provide the most powerful cloud based ALM solution to our users.

Build in the Team Foundation Service Preview provides a pool of build machines that are standing by ready to compile, test, and package your application. Gone are the days where you need to setup and maintain your own isolated build machine. If you’re a user of the Team Foundation Service Preview, we’ll do that for you.

Setup

There is none. Seriously there is no setup. All you have to do is create a build definition as you normally would and simply select the “Hosted Build Controller” and you are done. All of the features of Team Build are supported, including gated builds and workflow customization.

Upon successful completion of your build the output will be checked into source control under the $/teamproject/drops folder.

Don’t worry if you don’t see the controller in our account right away, we are enabling accounts in batches today so just keep checking back.

image

 

Frameworks and Dependencies

The only major limitation with build is you don’t control the build machine. That simply means that if you have an external dependency in your project you will either need to check it in or enable your solution to download it from a public NuGet feed.

The exact set of supported frameworks will continue to be refined, however with this release we have the following installed on the build image:

  • Visual Studio 2010 SP1
  • Visual Studio 11 Beta

This should allow you to build any of the project types that ship in the box for both of these releases with the exception of Windows Metro Style applications in VS 11.

Unit Testing

No build service would be complete without the ability to run your unit tests. For build on TFS preview we have brought all of the great new features of unit testing available in the Visual Studio 11 Beta (to learn more see What's New in Visual Studio 11 Beta Unit Testing). One of my favorite features is support for multiple unit testing frameworks.

For this example we are going to enable the xUnit framework for our project, however, the steps we are following will work for any supported framework.

  1. To get started you will need to download the appropriate test adapter for your framework. You can find the xunit adapter at http://aka.ms/xunit-vs11. When the download starts you will want to save the .vsix file to your hard drive so you can find it.
  2. Once the download is complete you will need to rename the .vsix file to .zip and extract the files. For our purposes we are interested only in the two .dll libraries contained in the archive.
  3. Take the xunit.runner.utility.dll and the xunit.runner.visualstudio.dll assemblies and check them into source control
  4. Finally you will need to tell the build controller where to find the assemblies so it can download them during your build.

a. Navigate to the Builds page of Team Explorer

clip_image001

b. Select “Manage Build Controllers…” from the Actions menu

clip_image002

c. In the Manage Build Controllers dialog select the Hosted Build Controller and click Properties….

clip_image003

d. In the Build Controller Properties page set the Version control path to custom assemblies to the path where you checked the adapter binaries in.

clip_image004

With these steps complete you can simply check in some code with xUnit tests and those tests will run as part of the build process and the resuls will be published back to TFS.

clip_image006

Working with Drops

Because builds are running in Azure the only storage location we have that is readily accessible to you is version control. The only major limitation is your drop location must be under $/teamproject/drops. This should prevent someone from accidentally naming a build so it matches a branch of your application source and messing up your source tree. There are some drawbacks to this solution; however, we will continue to think through different options for the future.

When builds are deleted either by user action or via retention policy we will execute a version control destroy operation against the drop location for that definition. For now there is no customization of this action so please use the retention policy feature of builds appropriately.

Because drops are in source control you will want to make sure you cloak the $/teamproject/drops folder out of any workspaces you have, otherwise you might find yourself downloading a lot of content on a regular basis.

clip_image008

I think that covers the basics. We hope you are as excited to try out build as we are about bringing it to you. We look forward to hearing your feedback and providing more great features in the weeks and months to come.

Leave a Comment
  • Please add 6 and 1 and type the answer here:
  • Post
  • Excellent job :)

    In our current build process template we've made changes enabling us to build and deploy ClickOnce products. Will this be possible with the hosted build service also? :)

  • Is there a way to specify a folder other than $/TeamProject/Drops? I'd like to be able to drop my builds into a Builds TP on the same TPC so that my users and my build definitions are not required to cloak folders to avoid syncing every build ever generated.

  • In my account "Factus" the builds are currently just sitting there. I've tried deleting and recreating build jobs and postponing / resuming builds. But they just sit there w/o the build starting. Is there a problem at the moment?

  • @LarsWa - We're taking a look.  I'll see if we can't get someone to investigate this...

  • Lars - We detected your problem about an hour ago and have been working on it.  Sorry for the inconvenience.

  • My initial read of this makes me think you can't have a single build definition that uses multiple test adapters, because you pointed the custom assemblies path right at the xUnit folder, and didn't mention putting a second custom test adapter in there. Is that accurate, or is it possible to just put a second set of binaries for a second test adapter in that location and have the build use them both concurrently?

  • Creating a build definition requires a build controller be defined for this team project collection. There may not be any controllers configured or you may not have permissions to view them. Contact your Team Foundation Server administrator.

  • In the Build section there is Deployed tab. Is there an easy way to deploy build output? Thanks!

  • Do you still need to check-in the xUnit Files and setup the Custom Assemblies path? If so, any ideas how to do it with Git on the TF Service?

  • Excellent job, It's magic indeed !!

    When could we have support on Coded UI and Creation of Azure Packages with the latest Azure SDK ??

    Thanks,

Page 1 of 1 (10 items)