Sunday, March 06, 2005

MSDN technical briefing: Visual Studio Team System (4th March 2005, London)

I attended an MSDN briefing on Visual Studio 2005 Team System on Friday. The briefing was given by Hans Verbeeck, Ajay Sudan and Sean Puffett (I can't find blogs for the last two presenters), and its purpose was to give an overview of Team System. The day included several demos of the product, lots of free biscuits and coffee and was held in the pleasant (but underground) surroundings of the Cavendish Conference Centre. There's lots of information about what Team System does at the MSDN website, so I won't try and explain it all here. Instead I'll try and give some details of the bits I found interesting.


The initial offering for Team System will be as four separate products. Three of these will be versions of Visual Studio tuned to different roles in the development process: Architect, Developer, and Tester. These three versions share various components with each other, but I imagine the Developer version will be the most popular. The fourth part is the Team System Foundation Server, which is the SQL Server -based back-end of Team System.

A little was mentioned about the pricing structure of the clients: MSDN Universal subscribers will be able to get a Team System client for a "small additional cost". However, each subscriber will only be able to have one of the three client versions (Architect, Developer, Tester); the Team Foundation Server will have to be purchased separately. I suspect that upgrading from an MSDN Universal license to a Team System license will be cheaper than purchasing it outright.


The demo of the Developer client showed off some really nice features, such as static code analysis (based on FXCop: apparently the guy who developed it now works for Microsoft), unit testing and so on. The static analysis module allows you to run a set of rules against the source code on compilation. This allows you to generate warning for things like the capitalization of variable names, but it can also spot other things like potentially unsafe pointer artimetic or array traversals (and it runs on native and managed code). All these rules can be tried to the checkin policy, so you can set up rules to only allow a checkin if all the static code checker tests pass.

The unit test facilities are also great (the actual tests are compatible with those used by NUnit). You can automatically create template unit tests at the namespace, class and method level simply by right-cicking on the appropriate part of the code. These tests can be built into a separate project, which you can choose to run at the end of every build. Again, you can set up checkin policies to prevent code being checked in that fails a unit test.

We also saw some of the features of the source control system. Being built on Sql Server, it scale pretty well (apparently, the entire Team System group is already using it, and they're planning to roll it out to the other Microsoft development groups this year). It gives you all the standard source control things such as merging, branching, parallel development and the like. They also have a client that runs over HTTP , so remote development isn't a problem. One nice feature is the ability to "shelve" currently checked-out files: this sends them back to the server for safe-keeping but doesn't check them in. Amongst other things, it allows you to easily return to where you are if you're interrupted while working on a given task.

As an aside, I was somewhat surprised to hear that they are still going to support Visual Source Safe: version 8 will ship with Visual Studio .NET 2005. They said that for teams of five or less, there was no reason to upgrade to Team System. That said, Team System is able to import a Source Safe database, so upgrading should be simple if required.

We also saw some of the reports that the Team System Foundation Server generates. Each project has its own "project webpage", built on Windows SharePoint Services, which can hold dynamic information about the status of a project. The build automation tools will automatically generate a large number of statistics at the end of each nightly build (things like unit test code coverage, code churn, number of bugs fixed, number of bug outstanding and so on). These statistics can be graphed and published to the SharePoint (or wherever) using standard SQL Server reporting facilities. These reports are intended to let a project manager (or other stakeholder) get an insight into the development process without needing to arrange a status meeting. It all looked pretty good, but the demo was a bit brief and I'd have to see it in action on a real project before making any conclusions.

The other demo that caught my eye was on Work Item Tracking. A "Work Item" in Team System speak is any unit of work (bug, feature, task, etc), and they're managed rather like tasks in Outlook. The nice things about Team System is the integration of work items throughout the entire product suite: testers can create work items for failed test cases, product managers can group work items into features, the automated build system will create work items for failed builds and so on. Work items appear to be very customizable - they're described using a bit of XML which makes it very easy to add new fields, rules, forms or states. They are also well integrated with other Office tools such as MS Outlook, MS Excel and MS Project. This makes it possible for a Project Manager to work with work items without firing up Visual Studio.

Thoughts and musings

Two messages came over particularly strongly at the conference. The first is that they have big plans for their next release. Somewhat disappointingly, the current release does not seem to have much support for C++ (for example, there's no support for C++ in the class designer). But the next version will have this much more - it promises to be something really special.

The second message that came across was that Team System is easily customizable. It appears that everything can be customized in some way or other, either by tweaking an XML file somewhere or by writing code to access an API. The most striking example of this is the ability to fit Team System to whatever process you're currently using. The boxed version of Team System ships with the Microsoft Solutions Framework and two process templates (one formal, one Agile), but you can easily extend these or add your own.

it was well worth attending this conference, and I'd consider going to other technical briefings on the strength of this one. If you're interested, the slides used at the conference will be available here from the 10th of March onward.


Blogger auntiesal said...

hi ste, just thought i'd post a hello since no-one else has so far! have no idea what you've written so can't possible comment anything useful but i can tell a good joke:
(you have to say it outloud)

knock knock

whos there?


biggish who?

no thanks

hee hee

2:00 PM  

Post a Comment

<< Home