Problems With Team System

The Cost

I don't mind Microsoft charging large quantities for VSTS for developers, its par for the course. However there are some things I do resent:

1. To do basic things like maintain the (AWFUL) VSMDI file or view code coverage results you seem to need to to have the tester edition
2. If your users want to interact with Team System, using the portal or TeamPlain, they need expensive CALs
3. There is no longer any database support, so you need to have team system for database developers.

To me its the first two that are an issue, and that really should be dealt with.

Feedback

I've found that the quality of Team System isn't that great, but I guess you expect that from the first version of such a large project. Features that we consider key, such as unit testing and check in policies, just do not work as well as we'd expect.

However what bothers me is that when I log these issues using Microsoft Connect all I get is "cannot reproduce". I can't argue with that but there seems to be two problems:

1. Far from fixing issues I've reported SP1 seems to have introduced new ones.


2. When you do get problems you get very vague error messages that give you no chance to fix the problem and that don't provide Microsoft with the information they need to fix the problems. Take the date time related error message that I get when my testing check in policy fails (which it does all the time).
3. As far as I can see SP1 didn't fix any of the issues I was getting but did introduce new ones.
4. Very old issues like this and this have been reported by several people but Microsoft make no attempt to indicate whether they are doing anything about them.

As an example of an error message...







...needless to say the related issue was immediately marked as not reproducible.

VSMDI File
I hate it, its a maintenance nightmare that we need to keep around because the check in policies and code coverage functionality needs it.

Release Cycle
With open source software you tend to get releases relatively regularly and on a good project each release improves the quality. I'm not sure if I would say this happens with VSTS.

Documentation
The online documentation is quite often very poor and you end up looking at the odd blog entry to get information. As an example we wanted to have one of our team system builds do the following:

1. Get the database scripts
2. Build them
3. Run the integration tests

Simple you might think, so how do we get the database scripts. Well we quickly identified we needed to use CoreGet. Do a search in MSDN and you get this page with this example:

What we thought, we can't specify a path within the Team Project to get, so we couldn't specify that we only wanted to get the "CrmDatabase" within the "Database" team project.

Our search continued and eventually we found this blog entry. Superb, just what we needed. So why didn't MSDN provide us with this information.

To be honest this is no isolated case, in general I'd say that 80% of the time we need team system information we find it in blogs rather than in MSDN, not perfect.

Open Source
Since we have so many problems getting testing and code coverage to work well in Team System I'm wondering why any company evaluating VSTS would choose it over open source.

I guess the whole integrated environment idea is a good one but when many of the integrated features don't work particularly well, and when each of them is expensive, and when the open source alternatives are in most cases at least as good...

Share This - Digg It • Save to del.icio.us • Stumble It! • Kick It • DZone