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 »
SD Times recently posted an article about TFS (and about VS Orcas). I’m only going to talk about the TFS part of it here and leave any thoughts on the broader VS and Vista comments to others to comment on. I think it’s a good and balanced article.
Both the good in the bad are captured in one quote in the article:
“The features that are in TFS…are pretty darn solid; they haven’t run into too many issues with them, doing…the typical things you might want to do with a high-end package. Once you begin to go outside the core, however, the story changes, he chuckled.”
It is also described as:
"typical of “a 1.0 release, with all that implies and intends.”"
In my opinion both of these statements are fair and appropriate. It's a solid product but is definitely a V1. There are unfilled gaps that are being filled by partners (like a web interface) and some features that are not as strong as we'd like them to be. One thing that helps to put TFS V1 in perspective is that set out to build the best integrated team development tool by combining a wide array of what have traditionally been distinct features/products. Our strategy was to build the most productive overall team development experience on the market and we recognized that to do this we wouldn’t have “best of breed” features in every area. Over the next few versions we will continue to build on and expand the integration while at the same time filling gaps and improving individual features into the best in their class.
Some specific things called out in the article...
It talks about the lack of continuous integration and the ability to schedule builds. It also talks about lack of a gui editor for build definitions. I think it's fair to say that TFS Build is the weakest of our "out of the box" feature experiences. It does a good job serving as an integration point - pulling together data from version control, work item tracking, testing, the build process and populating the warehouse. However, much of it is manual. Build is one of our biggest areas of investment in Orcas - including better extensibility, continuous integration and lots of other features.
It also talks about how cool checkin policies are but laments that deployment of them is manual. This is a good observation and clearly a gap we need to fill. I wish I could say it was in our Orcas plan, but it is not at the moment. There are a variety of ways to deploy them, including manually, SMS, Group Policy, etc. We'll get to filling this gap but, quite honestly, it hasn't been one of the most requested enhancements so far.
It also calls out the great things about the work item tracking system but points out “If you want to edit one, you get a big giant XML file and you start typing,” (referring to work item type definitions). Clearly we never meant for people to edit the XML for long :). Fortunately Joel Semeniuk and friends wrote a handy UI and made it available to the community. We have picked up Joel's work and begun building on it. In the next month we will be releasing an enhanced version to the web that will support more complex work item types, include a graphical work flow designer and other enhancements.
Another aspect of work items that it covers is the importance of being able to interface with other systems (in this case PeopleSoft). We hear every day from customers how important this is have a couple of irons in the fire to address it. First we are building a "migration toolkit" that is a set of class libraries/tools that we plan to release in source code form that make it as easy as we can to enable either "conversion" or "bidirectional mirroring" with other systems. Along side of this we will be releasing tools for several of the most popular systems. I expect to see early versions of some of this to become available over the next few months.
It closes talking about scalability and tight release cycles. These are clearly trends in the industry and exactly the kind of scenario TFS was built for. We look forward to helping customers evolve their development processes to meet this challenge.
This post is not intended to cover a complete roadmap of TFS over the next few versions but rather just explain where we are with a few of the issues outlined in the article. I plan to release a full roadmap including all of our planned Orcas features and the direction for the version after that before the end of the year. Keep your eyes peeled - I look forward to hearing your feedback.