Microsoft is quickly moving the world towards SharePoint for everything application-related including TFS. Don't be surprised to see me write about SharePoint-related matters here as they greatly impact the possibilities with TFS.
I'd like to provide an article that covers how to create a basic custom site definition, how to create a basic custom list definition, and how to display that custom list on the default page at site creation. This knowledge is useful in TFS as SharePoint lists are great for collaboratively working with constituencies in setting priorities, gathering requirements, reporting bugs, reporting bad implementations and coming up with todo lists that are meaningful. Build your custom list templates right and you'll extend TFS functionality more properly.
See http://www.heathersolomon.com/blog/articles/1300.aspx for the article. And I'd highly recommend reading http://msdn.microsoft.com/en-us/library/ms946721.aspx to get some understanding of CAML as it relates to custom views.
Subscribe to:
Post Comments (Atom)
I'm not so sure that Sharepoint is any longer a "strategic" part of TFS. My understand (I could be wrong) that the Sharepoint Portal was originally intended as the primary "Web" access for TFS (ie as an alternative to Visual Studio - especially for non-developers like Managers and End Users)
ReplyDeleteThis was before Microsoft purchased Great Plains and delivered the "TFS Web Access Application".
While the Sharepoint Portal can be useful for its Document Repository, the tools for editing the Guidance pages are too limited. I don't know of anyone who's actually done it.
That said, and speaking as a TFS expert and Sharepoint novice - I look forward to your ideas to see how Sharepoint can add value to TFS (as I just don't see it as it stands today)
I appreciate your comments fuzzbone. You bring up some interesting points.
ReplyDeleteBy "TFS Web Access Application" don't you mean Team System Web Access (TSWA)? TSWA is certainly a good web application to give a web browser interface into TFS for licensed TFS end users that don't install any client software.
However the direction that Microsoft has been pushing is for organizations to build applications and services on the SharePoint platform. With TFS I've seen that teams/organizations can collaborate and do their workflows more effectively. I get plenty of mileage out of Sharepoint content that's related to a Team Project. Linking discussion threads to applicable work items is important for effectively marrying requirements analysis with design/development. I recommend editing the Guidance pages in Visual Studio along with any of the other Process Template files within an organization's .NET solution (version-controlled in TFS) for their own organization-specific custom Process Template. And I especially recommend getting a strong understanding of the .NET namespaces associated with TFS and Sharepoint - i.e. http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.aspx, http://msdn.microsoft.com/en-us/library/microsoft.teamfoundation.aspx, etc. That way I can build simple, useful tools to integrate TFS, SharePoint and anything else together in order to make TFS a one-stop solution for managing the operations/future of an IT organization.
I'll be very interested to see what Brian Harry or others have to say about the future of TFS and SharePoint together. I got to imagine that the SharePoint/MOSS proponents in Redmond are going to be battling hard to push for tighter integration of SharePoint with Dynamics (i.e. Great Plains), Office, TFS, IIS, Exchange/Outlook, etc. to be the platform for applications/services.