locked
Shared Components between VSTS Projects RRS feed

  • Question

  • How would one share component development between two VSTS Project teams?  Is this possible?

    For example a team may be responsible for common UI components shared between between other projects.  This development may be in tamdem.

    Thursday, April 6, 2006 8:15 AM

Answers

All replies

  • If you have a component that is common to multiple projects, one option is to use a separate team project for that component and only share the built component (binary reuse) with other projects. This will allow different teams to take dependencies on known versions of the component coming from that team project.

    As you may know, there are countless articles out there on component reuse. Our patterns & practices  team covers it in this article:

    http://msdn.microsoft.com/practices/Topics/arch/default.aspx?pull=/library/en-us/dnbda/html/apparchch2.asp

    In addition, their Enterprise Library (http://msdn.microsoft.com/practices/compcat/default.aspx?pull=/library/en-us/dnpag2/html/entlib2.asp) is an example of component reuse. Imagine building applications that resuse the components in this library. The best solution would be to maintain the library as a separate team project with specific builds advertised for reuse. For example, separate builds of the Enterprise Library are available for use with .NET 1.1 and .NET 2.0 projects.

    Friday, April 7, 2006 1:37 AM
  • Hi Rob

    Just been on a course for TFS and this subject of shared projects and implications upon team builds was definately a problem area for allot of people. The area around Team Build also seems a bit fragile unless it's a project that doesn't rely upon share components from other projects.

    It seems impossible to build a core project and a shared project in the same build process, is this true? Or is this specific to a workspace.

    Our instructors referenced us to this url; http://blogs.msdn.com/manishagarwal/archive/2005/12/22/506635.aspx

    This is fine (if smells of fudge) andd your answer is fine, but this is going to cause a real problem for allot of people (this was evident from the course I attended).

    What's the way forward on this?

     

    Thanks

    David

    Friday, April 7, 2006 2:32 PM
  • I'm curious if you could expound on the circumstances you have run into  and under what conditions on the build for core and shared projects? I am no BuildMaster but do expect to increase my knowledge significantly in the build area over the next 6 weeks. I see this as something I need to understand better. What did you encounter that presented the problem and prompted a statement that it 'seems impossible...' ? I'm no disagreeing. To the contrary I am asking what lead to that conclusion.

     

    Thanks!

     

    Friday, April 14, 2006 7:13 AM
  • I believe that sharing components from multiple Team Projects at the source code level is quite feasible by means of Workspaces, if sharing at the source level. Or by simply adding the resulting executable from one Team Project to another.

    However, the part that concerns me more is the concept of traceability across multiple Team Projects.

    Suppose you are in the QA process for your application (TP1) and one of your testers finds a bug for which they create a corresponding Work Item. This bug is assigned to a developer who then determines the problem really lies in one of the "core" components, which is part of another Team Project (TP2).

    How does one communicate, but more importantly maintain a trace from TP1 to TP2? At some point TP2 will deliver a new version that will solve the bug. Do we just manage this traceability manually? How does a Project Manager get a status of their bugs with respect to work being done in another Team Project? Is the use of Work Item links with cross-project queries sufficient to do this? How does MS manage such a situation?

    Tuesday, April 18, 2006 7:56 PM
  • Our entire division lives in one team project.  Search on my posts here for more details.

    I'm not a Work Item Tracking expert, but just playing around it appears you can create/move a bug into any Area Path or Iteration Path on the server (regardless of TP) so long as you have permissions.  The bigger question is whether any of your existing queries will find it -- probably not, since by default every query starts with "Team Project = @Project" as the first clause.

    If we do have a bug that needs to be filed against a completely foreign bug database (e.g. Windows), the bug gets resolved as "External" on our end and manually added on the other end with "Source = External"...both bugs will put the # and area path of the corresponding bug in an appropriate field.
    Tuesday, April 18, 2006 9:28 PM
  • Thank you for the clarification. The concept of "External" may do the trick. I will try to go through an example in our sandbox when I have a chance to observe this concept in action.
    Wednesday, April 19, 2006 12:04 AM
  • Would you recommend NOT using separate Team Projects if this "shared framework" scenerio exists?  What advantages of separate Team Projects are you missing out on by using this technique?
    Friday, June 9, 2006 6:53 PM