Wrox Programmer Forums

Need to download code?

View our list of code downloads.

Go Back   Wrox Programmer Forums > .NET > Other .NET > BOOK: Professional Team Foundation Server ISBN: 0-471-91930-6
Password Reminder
Register
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read
BOOK: Professional Team Foundation Server ISBN: 0-471-91930-6
This is the forum to discuss the Wrox book Professional Team Foundation Server by Jean-Luc David, Mickey Gousset, Erik Gunvaldson; ISBN: 9780471919308
Welcome to the p2p.wrox.com Forums.

You are currently viewing the BOOK: Professional Team Foundation Server ISBN: 0-471-91930-6 section of the Wrox Programmer to Programmer discussions. This is a community of tens of thousands of software programmers and website developers including Wrox book authors and readers. As a guest, you can read any forum posting. By joining today you can post your own programming questions, respond to other developers’ questions, and eliminate the ads that are displayed to guests. Registration is fast, simple and absolutely free .
DRM-free e-books 300x50
 
 
Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old April 9th, 2007, 05:10 PM
Registered User
 
Join Date: Apr 2007
Location: , CA, USA.
Posts: 1
Thanks: 0
Thanked 0 Times in 0 Posts
Default Tips for organizing Team Projects?

All, we're about a week away from our first stab at setting up TFS. A small team went to two days of TFS deep-dive, and got a great overview of how the system works and some info on limitations and workarounds. I need some advice on the part that worries me the most, the way Team Projects are organized.

Here's my situation: I work in the IT dept. of a 3,000-person company. We have a lot of COTS apps with customization and configuration, and a moderate amount of app development -- web apps, reports, middleware, etc., mostly for internal use. We're in a single geographic location, have a single data center, and about 20 developers and an ever-changing cast of consultants who need access to source control. We have a Project Management Office (PMO) and an app maintenance group, and about 150+ applications to support, each with one or many projects. We're currently using VSS 6.0 :-(

Projects may get initiated through the PMO, worked on and eventually transferred to the Maint. group once they go live. Or, if small enough, they may originate in the Maint. group, either as brand-new work or as enhancements to existing systems.

At our training, we were told that ALL TFS Team Projects must hang off the root:
Code:
$/Project1, $/Project2,
etc. And, there's a limit of ~500 Agile projects on a server. We could easily have 500+ projects, if they all hang off the root.

In VSS, I can create subprojects, so my repository root can be fairly clean, and all the real changing items are a couple levels deep. E.g. in VSS I can have
Code:
$/PMO/Financial Systems/FinProject1
$/PMO/Property Management Systems/PMSProj1
$/Maint/Intranet/InetProj1
$/Maint/Middleware/Messaging/IntProject1
$/Maint/Middleware/ETL/ETLProj1
But the root just looks like
Code:
$/PMO
$/Maint
From what I can tell, in TFS, all these projects must hang off the root, either like
Code:
$/FinProject1
$/PMSProj1
$/InetProj1
$/IntProj1
$/ETLProj1
or
Code:
$/PMO_Financial Systems_FinProject1
$/PMO_Property Management Systems_PMSProj1
$/Maint_Intranet_InetProj1
$/Maint_Middleware_Messaging_IntProject1
$/Maint_Middleware_ETL_ETLProj1
That causes me some pain: We have LOTS of projects, and not much consistency in naming conventions. So it could be very hard for people to locate the project they should work on. Grouping by the dept that owns the project, and by functional categories below that, makes it pretty easy to zero in on the items of interest. And we'd never get near the 500-project limit if we could group them.

Our team has been kicking around ideas to deal with this. One is to go ahead and make the owning depts. the top-level "Team Projects", and the actual development artifacts as sub-sub-folders within that, just like the VSS example above. But from what I understand, ALL projects under that root TP must share the same Methodology.

What other limitations does this structure imply? How do people in corporate IT environments like mine deal with this? Any tips appreciated!

 - Val

 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Team Foundation Server / Team System aytacakin Visual Studio 2005 2 March 27th, 2006 01:36 AM
hints and tips needed Vano2005 C# 6 July 13th, 2005 11:42 AM
How to make Tool Tips when onmouseover bekim Javascript How-To 5 February 2nd, 2005 08:53 AM
Tips/Tricks - Record Finder Code JeffChr BOOK: Access 2003 VBA Programmer's Reference 2 January 6th, 2005 08:07 PM
Tool Tips in C# DAK BOOK: Professional C#, 2nd and 3rd Editions 0 January 8th, 2004 12:35 AM



All times are GMT -4. The time now is 02:21 PM.


Powered by vBulletin®
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.