Sonal Pardeshi - Using VSTS's Source Code Management

Rob Caron has a nice article on his blog where he explains how the different versions of Team System relate to each other.

http://blogs.msdn.com/robcaron/archive/2005/04/15/408426.aspx

It's an old article, but it still communicates the basic structure well.

In a nutshell though, all the "Source Code Management goodness" is part of Team Foundation Server. You need the server in order to use Version Control, Work Item Tracking, Team Build, Reporting etc. All the other "Team Edition for XXX" versions and VS 2005 Team Suite include Team Explorer - the part of the IDE that acts as a client for Team Foundation.

I'm not sure whether this is sufficient detail for you - so if you want more let me know and I'll see what else I can do to clarify

Pronob - thanks for the feedback, and I'm really glad to hear that Team Foundation looks like a good fit for your team

Pronob wrote:

Hello John,

I heard you saying that the reports, apart from viewing them through Visual Studio you can also view them through Reporting Server. My question is...does creating a team project create the report portal with all the reports as well... similar to Sharepoint team project portal that gets created?

Any clarification in the manner will be highly appreciated.

Absolutely - when a team project is created we create a number of different databases for Version Control, Work Item Tracking, Team Build and general administrative functionality. Additionally we create the Sharepoint portal, and we create a Reporting Warehouse and the associated reports, which are pushed onto the Reporting Server.
The Sharepoint portal is automatically linked to the reports too - so if you navigate to the project homepage you can follow links to the reports, or even include them as web parts on the front page if you want.

Hope that helps!
John

TheAsher wrote:

I'd like to know how TFS (and the rest of VSTS for that matter) relates to Microsoft’s 'eating our own dog food' motto.
Yes, I've heard the VS team uses it.
But what about other teams will be using it ?
Okay, the Windows, SQL, Exchange, Office products are not a match for TFS, but what about other products, smaller ones, like BizTalk, ISA Server, Data Protection Manager.....

I feel (and partially know) that as far as it goes for development tools and platforms there is much less 'eating our own dog food' at Microsoft...
For example, is ISA server really developed with Visual Studio (from what I've heard it is not the case)
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->

Great questions. I wish I could answer your question about ISA server, but I honestly don't know how much they use Visual Studio.

Generally you can't roll out dogfooding to the entire company overnight. We need to build things up and make sure we scale and meet each organizations requirements first, so we're doing things in a more controlled approach and engaging with different teams over time. However, in general there is a great deal of commitment to ensuring that TFS becomes the long term internal standard for all Microsoft s/w project management, and a lot of our v2 planning will be done with this in mind.

However, I'm sure you're interested in what is happening about dogfooding TFS today.

Firstly, the VS Team is huge - and I have to be honest and say that not all of VS is using TFS yet. The bulk of the dogfooding in VS has been by all of the Visual Studio Team system teams (which is still a very large user base - see this article on my blog for stats). However, there are other teams in DevDiv using TFS too, and we're currently working on exploring how to move all of devdiv over - but there are a lot of internal tools built on our old technologies which will need moving over, and this takes time. Fortunately, now that Whidbey has shipped we're taking some time out to do a bunch of projects to update our engineering infrastructure - and this includes the way we consume TFS dogfood (we're even using TFS to track this effort)

For other organizations, we're bringing on as many other internal teams as we're able to support at the moment. We're spinning up a Solution Provider team inside of the VSTS organization specifically to help bring other teams on board and help them plan & implement their migration to TFS. Until we RTM, we're in a position where we have to do much of this support ourselves so we have to be quite strategic about which teams we bring into the dogfood program.

We have a number of smaller teams on board at the moment including internal IT teams and teams working on external products and we're working with some of the larger teams on your list above too - although I don't think we have anything we can announce yet.  

I feel like I haven't given you specifics here - I will try and find out if we have some more specific information I can publish.

However, one final point I want to make - although we don't necessarily dogfood TFS v1 internally across 100% of Microsoft development teams, we do dogfood the previous version of TFS Work Item Tracking for all product development. This has been in use for several years, and the code (and team) formed the basis for for Team Foundation's work item tracking tracking. While this isn't true dogfooding of our final TFS product it still shows that the code & technologies we use are are already being heavily consumed here at MSFT.