Even though the Team Foundation Service can be updated more frequently than a typical boxed product (current updates are scheduled approximately every 3 weeks), there were some gaps between this service and Team Foundation Server. One of which was building solutions and projects in the cloud. Prior to today this was only possible by procuring a VM or a physical machine, turning it into a build server/controller and configuring it to “talk to” the service. All of that has now changed with the introduction of a Hosted Build Controller (HBC).
While you still may want to use a local machine since you’ll have full control over it, having the ability to set a build definition (BD) to a HBC is extremely appealing for a number of reasons. First and foremost is that no infrastructure is needed and therefore the release lead/manager can setup multiple BD’s (e.g. Continuous Integration, Gated Check-in’s, etc.) quickly which means the development team(s) can see the fruits of their labor in no time. Add in collaboration between the development team(s) and it’s a win-win situation all around.
So, how does one actually configure a build to run in the cloud? It couldn’t be easier. After the initial connection from your local workstation to the service is complete, simply select the “Hosted Build Controller” option from a new (or existing for that matter) BD and then the build will now be run by the HBC.
I’ll also mention that just like a local BD, you have access to the parameters and advanced settings.
Lest we not forget the testers, the HBC does more than just compile code as it can execute unit tests using MSTest or the new native C++ unit test framework. 3rd party integration does require some additional configuration (e.g. NUnit, XUnit, etc.) but if you follow the Visual Studio ALM blog they have a great post on this exact topic.
As with anything shiny and new there are a few caveats to be aware of. UNC’s path aren’t allowed (we are “in the cloud” after all) so the drop location will be contained within the Source Control repository (in my example “$/Training/Drops”), however you can still set the location of this folder. Since you don’t have access to the file system, when builds are deleted the associated files are as well. Here using manual intervention or the Build Retention Policy for the BD will dictate how and when these deletions occur.
Since the HBC is just a VM image it has limited support for frameworks, specifically for Visual Studio 2010 SP1 and Visual Studio 11 Beta created solutions. 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. I’m sure more components will be added for not just Windows 8 but for other elements as well.
If I made a wish list, the one item that would be at the top of it would be the ability to create a new BD directly from the web site. Sure, if you’re a part of the team you’ll most likely have either Team Explorer Everywhere or Visual Studio (VS) but I think having this as part of the web interface would be a big benefit. Case in point: I’m running VS11 Beta within a VM so I had to start the VM, launch VS, connect to TFS and create a new BD. I mean, if I can queue a new BD, it’d be nice to create one as well. Just sayin’…
That being said, the work done here is again astonishing as it adds a feature that while was offered by our partners should most certainly be a part of our hosted solution. Hopefully in the not so distant future, SQL Server Reporting Services (SSRS) will be added along with SharePoint integration. If the HBC is any indication, instead of waiting years, it’s only going to be a matter of months (or less) before this and other features become available.
Note: If you’re using Visual Studio 2010, you’ll need this update to connect to the Team Foundation Service.