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 »
Last month I wrote a post describing a cool, streamlined, web based Agile project management solution we are building. Over the next week or so I’m going to write a series of posts covering another area we’ve been working on. We call the scenario “Developers are Raving Fans”.
In the 2010 release of Team Foundation Server, we spent a disproportionate share of our time working on infrastructure improvements. Scale up, scale down, scale out, disaster recovery, reliability, backup/restore, simplified install, flexible configuration, patching, administration, etc. etc. They were very important improvements that really helped enterprises adopt TFS, set us up for hosting TFS in the cloud and at the same time enabled us to create a “TFS Basic” install experience that anyone can get working quickly and easily. However, the result was that we didn’t get nearly as much time as we would have liked to make improvements that make the life of the developer in the trenches day in and day out a ton better.
In Dev 11, we’ve rebalanced to focus a lot more of our energy on streamlining the day to day workflow and addressing long standing wish list items that we’ve heard over the past few years. The result is an exciting release that feels like it’s way bigger and more compelling than the 2010 release was for the front line developer.
I thought about trying cram it all into one post. But over the past couple of weeks I’ve been to two events where I had the opportunity to demonstrate the new features of Dev 11 to our field (sales, support, MCS, evangelism, etc) and I’ve come to realize how daunting that is. I had 3 1/2 hours with our sales field last week and was unable to finish a demo of everything (intermixed with Q & A). As a result, I’m not going to try to take it all on at once but will rather spread it across many posts.
One of the biggest areas of feedback from developers has been on our version control solution. For some work styles, people feel Subversion or Git are more natural and fluid solutions. In my next post, I’ll talk about some of the improvements we’ve made to version control to make it support those work styles much better. I’ll start it now. Expect it later today or tomorrow morning :)