Everything you want to know about Visual Studio ALM and Farming
Brian Harry is a Microsoft Technical Fellow working as the Product Unit Manager for Team Foundation Server. Learn more about Brian.
More videos »
OK, so maybe I didn’t need to tell you that. Or maybe, you observe that it isn’t quite true because summer officially starts in about a week. But then that’s not really what I mean.
I’ve written little tidbits about our transition from an organization shipping a box product every couple of years to one still shipping a box product but also shipping a cloud service every 3 weeks. There have been changes to virtually every aspect of how we work. One of those aspects is planning.
For our cloud cadence work, we have moved to a 6 month planning cycle. We roughly draw out our vision in 6 month phases. We still maintain a priority ordered backlog and pull things off in 3 week increments but the 6 month cycle provides some overall direction that we use to help prioritize our backlogs and decide what order we are doing things in. One 6 month period is Jan 1st – June 30th (called “Spring”) and the other is July 1st – December 31st (called “Fall”). I guess we only have 2 seasons – but hey, if you’ve got to pick two seasons in my neck of the woods, those are two good ones to pick
So, Spring is over.
Round about 6 months ago, we set out a vision for this Spring and it was briefly summarized as “Go Big!”. It entailed a series of investments that would ultimately culminate in the announcements we’ve made in the past couple of weeks – The TFS/Azure continuous deployment scenario which enables a smooth workflow for agile teams building Azure apps and the opening up of the Team Foundation Service to anyone and everyone who wants to use it. There were many investments along the way that ultimately enabled these end results, including:
A build service – The build service, in and of itself, is a darned useful thing. However, it was all part of the plan to deliver Azure continuous deployment. This is a good example of building larger scenarios in smaller chunks and releasing them independently while ultimately working towards an ultimate goal.
The new “welcome” experience – The new landing experience was an important part of providing an easy way for the larger group of people we knew would come visit the service to find out what the heck this service is and how to use it effectively.
Licensing changes – Making Team Explorer Everywhere more accessible and easier to use with Team Foundation Service.
Multi-tenancy – To handle the much larger volume of users and accounts, we had to make some significant changes to ensure we could operate the service cost effectively enough. The biggest of these was multi-tenancy that allows us to share costs (though, not data) among multiple tenants. This cut our costs by more than a factor of 20.
Improved performance and scale – In addition to managing the costs, we did a bunch of work to ensure the system scaled, performed well and was robust under heavy load. The gradual growth of the service afforded by the invitation code mechanism was a great way for us to manage this carefully.
Cloud mechanics – We built lots of underlying capabilities, like Feature switches, that enable cloud deployment models. Feature switches, for instance, allow us to deploy new capabilities to the service but selectively turn them on so we can effectively “beta test” them on the live service.
It’s been a busy and productive 6 months. We’ve learned a lot and shipped a bunch of great new features. Of course, all of this happened while simultaneously delivering the Team Foundation Server 2012 product (Release Candidate is now available). Pretty much everything we wanted to do for Spring is done and we are now framing the Fall release wave. As with Spring, you’ll continue to see a steady stream of new improvement every 3 weeks that will ultimately build into an experience we want to deliver by December. It’s been a fun way to approach things.
Looking forward to a great Fall!