Team Foundation Server on Windows Azure: A Rangers dog fooding perspective

Willy-P. Schaub

September 28th, 20110 0

Team Foundation Server on Windows Azure was announced at //BUILD/ and has received phenomenal coverage to date. The Visual Studio ALM Rangers have been dog-fooding the technology for some time and I thought it was important to highlight that “we love it”

Are we dog fooding or tinkering?

Initially we were exploring, researching and testing the waters with our big toe, or is that our big keyboard? When we started planning the infrastructure for our latest Rangers “Gig”, see Understanding our Visual Studio 11 Readiness conspiracy, we asked all the Rangers whether to remain on our existing infrastructure or to move to Team Foundation Server on Windows Azure. The vote was unanimous and we agreed to continue dogfooding the environment by moving all our Team Projects to the new world.

We first used the TFS Integration Tools (Platform) to migrate existing Team Projects, which is where the Getting Started Nuggets,mentioned in TFS Integration Tools (Platform), emerged from.
We then created all new Team Projects on the new environment … in essence we are not only dog fooding, but banking out biggest “Gig” on this environment.

Stats for those that need it

Today we have the following adoption to report to those interested in some basic stats:

24 team projects,of which 3 are for research and testing, the rests used by the Ranger project teams
120 Ranger members, working on the 24 team projects.

What are some of the key features we “love”?

I could create a monster post by summarising the all of the dog-food, the associated love and hate feedback, but for the sake of time, I will conclude this post by highlighting three features we have fallen in love with and which are proving to be real productivity features:

We have been and are running the latest bits, with zero maintenance and administration efforts for us. Most Rangers have not even noticed the regular updates of the back-end, other than tripping over new features and the continuously evolving web client.
The web client and especially its drag and drop support make the backlog maintenance a fun experience. Initially we pondered over why the backlog priority was hidden and we were unable to specify explicit priorities. When we realised that the priority was updated as you dragged and dropped items, we became used to the more intuitive and far more productive way of planning.
The third feature which I will cover in this post is the most exciting feature for anyone interested in the health of the project. On the backlog we have (1) a burn down chart and (2) detailed visual status of the work details.
Hmmmm … but there is more, this visual status is “real-time” which means that you no longer have to make your changes hours before the status meeting and that you can moth-ball the utilities we used in the past to force the reports to refresh.

… the not to forget to mention the awesome planning board