   Team Foundation Server
  Comments for the review of Team Foundation Server
  test, to check against this problem.   ;  I wanted to point out a couple of things.  First of all, this review concerns the 2008 release of VSTS; there will soon be a beta release of the 2010 version which improves the client UI and adds a number of new features... for example, hierarchical views of workitems/tasks, so that you can see linked workitems and dependencies much easier.That said, a few other points about the article, which I'll just number instead of trying to present in a coherent manner :-)1) Sweetest TFS feature for regular devs, in my humble opinion: Shelvesets.2) The article conflates Visual Studio Team Suite (which is all client VS stuff), Visual Studio Team System, and Team Foundation Server.  TFS has no dependency on the VS tools, and you can use some of the VS team tools without TFS (sweet profiling tools, testing tools, etc).  Generally, you will see them all used in conjunction.3)  You don't NEED Sharepoint.  You do need SQL.  And you do need IIS, as web services are the primary means of communication with a TFS instance.4) The article didn't review some of Team Foundation Server's most powerful features, namely its ridiculously robust reporting features and its ability to integrate quite well with Microsoft Office.  You can batch edit work items in Excel and that sort of thing.5) The point is valid that VSTS is expensive for small teams and hobbyists.  It is designed to scale to the needs of HUGE development organizations that have potentially thousands of developers, Sharepoint server farms, dedicated build/source control farms, labs full of test machines, etc., so keep that in mind when comparing it to other tools like SVN (which I happen to like quite a lot ;-)). As an example of how big this is intended to scale (with reporting example, to boot!) look at this blog entry detailing the extent to which TFS is used internally at Microsoft... over 50,000,000 source files in version control with 15000 users.But as you mentioned, perhaps MSDN subscriptions offer some things that put TFS+TE within reach of many smaller teams.  I'm not familiar with that.6) Regarding the project portal sites: no offense, but you did something wrong when you were looking at the web access stuff.  The web access provides a fully-functional alternative front-end to the same TFS data that Team Explorer accesses.  You should be able to see all of the same work item data, etc.  If you wouldn't mind posting a screenshot of the web app you were viewing, maybe I can help out in addressing that problem.  [EDIT: I think you were looking at the root Sharepoint site collection... it has "Calendar", "Documents", "Tasks", etc.  That is a Sharepoint thing, not TFS.  To look at your actual TFS tasks, go to the actual project portal... there they will be the same tasks you see in VS.  The reason the documents sometimes matched is because VS uses the Sharepoint doc library...)7) Regarding "workitems" versus "tasks" etc... in TFS everything is a "workitem".  You can create/define any type of workitems you like, defining their fields and even the UI for filling them out via XML.  Typical workitem types are "Bug", "Task", etc.  Those queries you see in the screenshot are editable queries, and you can create your own... if it says "Active Bugs", for example, that is just a query for "SELECT * From WorkItems WHERE [State] = 'Active' AND ['WorkItemType']='Bug'".  You can construct those queries using a query editor tool in VS.I'm sure I'll think of more points. :-)[Edited by - smitty1276 on April 22, 2009 8:02:25 PM];  Don't forget the support for automatic builds off triggers using MSBuild - you can set up a continuous integration integration environment extremely quickly.   ;  Hi,thanks for your comments. I admit that the review could have been better. I didn't describe a lot of features (and I really mean A LOT), and I surely have not such a deep experience of it assmitty1276.Nevertheless I'ld like to address one or two things:TFS is the basis for all other VST Packages and it is true, that it doesn't depend on VS to run. Nevertheless, I'm a developer and as such I'm interested how and in which way this interacts with my VS. As someone who works off-side with clients who have installed TFS on-site but no VS for the managers, I also have to keep in mind those guys. Believe it or not, for some managers don't install VS on their machines, so they don't have the Team Explorer.Then, when you want to access the TFS stuff through a web browser, you have to install the Team System Web Access stuff (http://msdn.microsoft.com/en-us/library/bb892990.aspx). This is something that should be included from start and not as a separate installation package. If you don't install this, you don't have access to the TFS work items, etc. And even then, not all Team Explorer functionality is included in the Web Access. I must admit here that some companies also have restrictive security and installation requirements, which sometimes lead to the situation that not everything get's installed (don't ask me for the reasons, I didn't get them either).This leaves the Sharepoint access for handling what a manager actually can do without installing Visual Studio (and Team Explorer).As for the reporting, I admit that I didn't use it yet as it should be, the team I'm working with is quite small and the TFS was intended as a "one software does it all" solution. We currently rely more on a quick turn around between software releases and the codebase is surely way under 50 mio source files...Perhaps we could do a more extensive review when TFS 2010 is available with you guys as reviewers?Thanks,Stefan   ;Quote:Original post by MetronBelieve it or not, for some managers don't install VS on their machines, so they don't have the Team Explorer.TE can be installed as a stand-alone TFS client, without Visual Studio.  TE and web access are what our PMs use.  Regarding Web Access, I believe that is installed with TFS now... the entire installation process is much better now.  The nature of the product (integration with other products, etc) means it will necessarily be somewhat complicated, but there is room for improvement.Quote:Perhaps we could do a more extensive review when TFS 2010 is available with you guys as reviewers?I would be open to helping out if I can, but I happen to be involved in the development of the product so I don't know if I should be "reviewing" it. :-);Quote:Original post by smitty1276I would be open to helping out if I can, but I happen to be involved in the development of the product so I don't know if I should be "reviewing" it. :-)*Chuckles* I used TFS for approx 1 year in my old workplace. Once you get used to the Microsoft standard way of setting up the structure, it's a beautiful piece of software.. shame about the price tag though.   ;  We use it at my workplace, and the one thing that most stands out to me is the performance. Or lack of same. It is amazingly sluggish, at checking in/out, at merging files, at everything. What really amazes me is that for some reason, if a merge conflict is encountered between two small, simple files (say, 50 lines each), it takes some 10+ seconds for TFS to do....... something, before you're even allowed to choose whether to resolve it automatically or open it in the merge editor thingy. I'm not sure what's going on in this time, but it certainly shouldn't be necessary.The interface in Team Explorer is generally speaking pretty awful. It seems like something that was slapped together in the last week before shipping. Options aren't exposed in context menus, you get big evil-looking ERROR dialogs at the slightest provocation (like a merge conflict), and if an *actual* error occurs, rather than a meaningful description of it, you get a complete .NET stack trace, taking up the entire height of the screen at 1600x1200. In a standard dialog box, meaning you can't even copy/paste it.When that is said, we're a small company, and we *definitely* don't use or need all the features it enables. I'm sure big companies like Microsoft are getting more mileage out of it.Quote:First of all, this review concerns the 2008 release of VSTS; there will soon be a beta release of the 2010 version which improves the client UI and adds a number of new features...I'm sure the 2k10 version will improve on this, and as usual, I expect Microsoft is going to keep slavering away so that after a half dozen releases or so, you end up with a very nice product, but future promises shouldn't really affect reviews of the current release, should they?   ;Quote:Original post by SpoonbenderWe use it at my workplace, and the one thing that most stands out to me is the performance. Or lack of same. It is amazingly sluggish, at checking in/out, at merging files, at everything.I know what you mean, and a lot of this is due to the fact that so much workspace information is stored on the server.  This has some benefits and it has some downsides, and one of those downsides is that some operations aren't as quick as they are when everything happens on the client.  I'm not sure about the particular operation/delay you're talking about, but I suspect it is one of these situations.Quote:I'm sure the 2k10 version will improve on this, and as usual, I expect Microsoft is going to keep slavering away so that after a half dozen releases or so, you end up with a very nice product, but future promises shouldn't really affect reviews of the current release, should they?Well, no, but certainly it's worth pointing out that a new release is forthcoming, with a beta in 3-4 weeks.;Quote:Original post by evolutionalI used TFS for approx 1 year in my old workplace. Once you get used to the Microsoft standard way of setting up the structure, it's a beautiful piece of software.. shame about the price tag though.I have no problem with the price tag, but I do have a problem with the first half of the statement.The tools should adapt to my preferred workflow, not the other way around.Like many others, I tried TFS for evaluation purposes.  TFS has cool error reporting systems that you can give to your testers, trusted clients, untrusted public, and others .... if you use their processes.  If you already have systems in place, you will need to abandon your system or write applications that integrate your system with TFS.  There are many excellent systems out there today that handle this for you.  For instance, if the company already uses a CRM system (like SalesForce) it can be hard to integrate.  But if you were using Microsoft Dynamics CRM , it would likely integrate easily.It has some cool end-to-end reporting features that can give lots of insight to your system .... if you use their tools and processes.  If you already had a system in place, you will miss out on their features or you will need to modify your existing workflow to the TFS way of doing things.  It has some really cool automatic build systems in place that can do some fun stuff .... if you are using their style of automatic builds.  But if you already have an automated build system and reporting (like BuildForge), it is almost certainly incompatible.The tools are Microsoft-centric, and if you are doing cross-platform or off-platform development you will miss out on some of the cool features.  This is to be expected of course, but will still be a source of frustration if you server farm isn't just Windows boxes or if your code base relies on languages not supported by Microsoft, such as Flash, Java, console compilers, and custom build tools.  It can be coerced to work with them, but it can be non-trivial to configure.If you are following the MS proscribed way of software development, I am sure the tools are probably absolutely awesome.If you aren't following the MS proscribed way of software development -- and few game companies do -- then the tools can be extremely difficult if not impossible to adapt to your your existing business processes.   