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.
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.
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.
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.
- 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.
- 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.
- Take the xunit.runner.utility.dll and the xunit.runner.visualstudio.dll assemblies and check them into source control
- 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
b. Select “Manage Build Controllers…” from the Actions menu
c. In the Manage Build Controllers dialog select the Hosted Build Controller and click Properties….
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.
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.
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.
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.