Sonal takes us into meet John Lawrence, development manager on on the
Visual Studio 2005 Team Foundation's Source Code Management team. You get to learn all about software project management and lifecycle. Why a daily build is important, how to track bugs, how to ensure that your development team follows policies, and much
more!

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

This is one of the best interviews/demos that i have seen. Your explanation and demonstration was very good and to the point. I am a dev manager in a small company with ambitious project plans. Team System is just the tool that I was looking for.

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?

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)

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.

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.

Hi JohnVery interesting to see how you are using TFS internally within your group - very pragmatic approach.

I am very impressed by the whole VS Team product set and particularly the TFS enabled capabilities around SCM, build management and overall analytics/reporting.

However, I am looking at a distributed dev environment across two locations (at least initially) and am not sure how TFS can be configured optimally for such a redeployment.

Given that you mentioned your team is distributed across at leat two locations (including India) I wondered if you have any thoughts or comments on the best distributed practices with TFS. I am paricularly interested in the soucre control and build management
issues as I am trying to introduce nightly build (and even continuous integration) practices from day one!

Nice work and appreciate and assistance you can give.

Remove this comment

Remove this thread

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums, or
Contact Us and let us know.