I have just arrived from Oslo, Norway. I conducted a three-day Team Foundation Server course for the students of the “Microsoft University .NET 2013” organized by Microsoft & Programutvikling (the organizer of the famous NDC conference, that goes to London too this year too). The TFS course was the last one of the course series for freshly graduated developers.

Conducting a course for a server product like TFS is always challenging. I like doing a lot of demos and hands-on exercises, but with a complex server setup in an unknown environment anything can go wrong (I had 21 attendees.) So this time I decided to use the TFS Service (the cloud-hosted TFS at http://tfs.visualstudio.com/) for the exercises. I have been anyway excited about TFS Service since the Git support is available and since we made SpecLog work with the hosted environment, so actually I was even happy that I could try how it would perform.

I did some tests before. It was clear that there will not be any problem with the source-control tasks. Neither the ALM exercises that depend heavily on the TFS web access looked fine. But the build… How will the build work? I wanted to let my students experiment with the build configuration features, so they were supposed to perform several builds, including test execution, NuGet package restore or gated check-in. The first tests looked promising: 1-2 minutes waiting time in the build queue and the build performance was also OK. But then I experienced much longer waiting times. In one case it was longer than 20 minutes. I got nervous a little bit. It was too late to change the strategy. The TFS virtual machine server on my notebook would have had probably also difficulties with 21 people testing build features at the same time. So – having no better idea – I prepared with a few jokes and extra demos that I can drop in when the classroom gets a 10-20 minutes idle time from TFS Service.

Finally everything went well. We saw very short queue waiting times (in most of the cases less than a minute) and as expected, the TFS service had no scaling issues with my 21 eager students. So I left the jokes for another occasion.

It is a part of the story that I tried to organize the build-related topics for the morning , when even the most hard-core geeks are already in bed in the US, but I don’t know if finally this was the key to the success. However, it is sure that using the TFS Service gave a bonus for the attendees: all their exercises remained at their own accounts, so they can review/test them later again.

Altogether there were only a few glitches with the technology (also thanks for Programutvikling for the high quality setup and organization). I had a demo at the end of the last day, where I made an automated UI tests, associated it with a test case work item and let it run on a “standard” lab environment through the “build, deploy & test” build strategy (consists of two builds and a lot of configurations). Even this monumental demo (needed at least 20 minutes to get to the final test execution) worked immediately… almost :).

This course also showed the potential in the hosted TFS service and I’m sure I will use it for even more things. (You can sign up for a TFS Service account in a few minutes for free.)