Partitioning: Sharepoint vs. Version Control
In a private reply to my recent post on TFS Partitioning, someone raised the question of team site partitioning. Basically, the question is: what should my team store in Version Control and what should we store in the Team Portal (Sharepoint)?
The guidance he has been giving to his customers is to track project artifacts that will no longer last after the project is complete in the Team Portal site and everything else such as product documents in version control. He also raised the option of storing product documents as attachments to workitems.
In general, I think about the Team Portal as a place to store anything you want to have very high visibility across all roles ;in the project. For example, process guidance, best practices documents, schedules, contact lists... - stuff that applies to everyone involved in the project. I think of Version Control as the best place to store items directly related to building the product (e.g. source code, test code, tools, etc.). Typically, developers and maybe testers will be the primary people who use version control. So my suggestion is to use the Team Portal for everything else so you don't have to train business analysts and project managers how to use Verison Control (not that they can't learn, of course :)). Another benefit of Version Control is the ability to view differences between versions of artifacts. But several file types such as Word documents already have an internal change tracking mechanism, so Version Control isn't buying you much here.
I do like the idea of bundling all specs & documentation together with source code when the project ends though. Depending on your definition of "end", you might be putting the project on ice forever, handing it off to a support team, or moving on to the next round of feature updates in your "always live" website type project if you're following more of a "real time" product cycle than a typical application product cycle. You might consider taking a snapshot of the pertinent Team Portal documentation and checking it into your Version Control repository at major milestones.
As for attaching artifacts to workitems... Well, the beauty of TFS is that it gives you the flexibility to choose among various options depending on what you need to do and who will be using it.
If, for example, you're considering using TFS as a sort of application platform like Customer A, then this might be a good path to take. They're looking into the idea of using TFS as the back-end data store and rules processing/notifications system for a pre-existing internal IT application for change request management. In this case, they would have a very friendly web-baesd GUI on top of the whole file attachment/workitem engine in a highly customized experience. In this case, you can create a new workitem type to track each change request and use it as a sort of "umbrella" task that links to all the related changesets, workitems/tasks, bugs, and test results related to completing the change request.
I'm sure there are many other scenarios where this would or wouldn't make sense. Based on my own experience with TFS and various teams & customers' use of it, I haven't seen many people using file attachments for things like product documentation. Usually, that gets stored in the Team Portal. I do see lots of screenshots, tracelogs, and saved e-mail getting stored as attachments, particularly for bugs.
Once again, TFS gives you the flexibility to create a process that works for you. I think we'll probably start seeing more best practices come together as customers continue their deployments and take TFS through full product cycles. As always, send in your questions & feedback so we can better understand your needs and in turn continue to make TFS even better for you.