none
What is a product family?

    Question

  • Let me see if I understand this TFS project structuring correctly.

    According to the picture I have below. I should create a product family folder for different Visual Studio projects (dll, wpf, asp, etc) in my TFS project?

    that way if I have a project that is a WPF app in VS and a project that is a dll in VS that the WPF app uses, they will both be in the same TFS project as different families (folders) and can be in the same Scrum iteration with shared work items?

    If this is true, what happens when I need to use the dll library, that I have in my TFS project as a product family, outside the TFS project? would I just use the dll?

    I'm not sure I fully understand what goes into a TFS project?


    chuckdawit




    • Edited by witdaj Thursday, September 20, 2012 11:26 PM
    Thursday, September 20, 2012 11:24 PM

Answers

  • Well, I'm an SQL guy so I don't have Team Projects with web sites:-) Nor can you accuse for spending too much time in scrum meetings; I try to avoid meetings as much as possible. And the only time I have heard anything about Scrum was when I attended a TFS class, but I was only interested in the version-control parts.

    Then again, I have enough experience of system development to have a general opinion. If you have applications A, B, C and D that all use library L, and you are working with A and see that you need changes in L, you need to talk with the person(s) who own L and they will have to plan the changes, which includes ensuring that none of the changes affects B, C, and D. Then they will implement and release the changes so that you can use them.

    Obviously, this model can be slow, since the library owner may be short on resources. An alternative in this case is that you incorporate the library in your project, and later backport the improvements to the library. But in the long run this will create more work. Not the least if you never do the backport.

    If you are a small group of people that own applications and the library, the distinctions get blurred. It can still be a good idea to adhere to this model, because in the long run your applications can uphold a higher level of quality. And at least there should not be any resource problems.

    From reading through the TFS 2010 book by Wrox its seems like you would want to put all your teams applications into a single team project in TFS and seperate them by "areas" and "iterations". Given you have a small team < 50 and you work on different applications simultaneously.

    Not really. First of all, what I say above is a discussion on general level without any specific version-control system in mind.

    My post was sparked by the fact that you seemed to be considering to have different team projects for different technologies, but maybe I was just misreading you.

    I can't say how you should organise your applications, because I don't know them. In the shop where I spend most of the time, about everything is one single team project (if we forget that we still have some stuff in SourceSafe, as we have not completed the transition yet). There are however some components that are seen as "general" that are in a separate team project collection. But here we are talking about one big application, and the idea of splitting it up in different team projects is just lunacy.

    I think for you one decisive factor for you is what release cycle you have for your applications. If A, B, C and D are always released in parallel, you could stick all under a single project together with the library. But if they are released independently, they should also be managed independently, and in this case you also need to have a strict regime for your library, so that application in a an early stage goes and changes the library and break app B which is planned to release next week.


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
    Saturday, September 22, 2012 10:23 AM
  • Hi Chuckdawit,

    I would say that there is no perfect solution to your problem. It is more a matter of taste and what will fit the needs of your company.

    Putting everything into one team project will give you the benefit of keeping one backlog across all applications, libraries etc. But it will make your area and iteration paths more complex and possible access restrictions on the code will have to be handled on a "deeper level".

    Putting each application, shared library and so on into a separate team project will make it much easier to manage access to that code and workitems within the team project. Basically making it easy if a team "owns" a specific application or code base. But at the same time, making changes in multiple team projects will give you the problem of keeping track of work items across the team projects.

    I have also seen a sort of mix of these two options where a team project is created for each application, library etc and code is checked into these team projects. Then, for each project started at the company a new Team project is created in TFS using a project template matching the dev process used in that project (CMMI, Scrum etc) but no source code repository is created for these projects. Code changes are made in whatever team project the code is located and when code is checked in you associate the change to a work item in the "project project" (I hope that makes sense). This aproach breaks some of the reports you get out of the box.

    I'd say thet neither approach is perfect, you will run into issues no matter what. Sit down and have a look at how you work (or would like to work) most of the time and chose whatever approach fits best. Maybe 90% of the time it will work just fine and the other 10% will include some pain. At least the numbers wont be reversed. With some adjustments and customization maybe these 10% will shrink.

    Finally, I would not put this down as a shortcoming of TFS. I have so far not seen a tool that simply solves this problem. If anyone has, I would be very happy if they told me about it :)


    JESPER FERNSTRÖM
    Transcendent Group

    Wednesday, September 26, 2012 11:59 AM

All replies

  • Hi Chuckdawit,

    Thanks for your post.

    Your ProductFamily1 and ProductFamily2 are the same product under your Team Project? If yes, I think you needn’t to another produce folder(ProductFamily2) for your ProductFamily1. Under Team Project, each produce folder usually contain their own product.

    For how structure projects under Team Project Source Control, please refer to the helpful information in this article: http://blog.hinshelwood.com/project-of-projects-with-team-foundation-server-2010/.


    John Qiao [MSFT]
    MSDN Community Support | Feedback to us

    Friday, September 21, 2012 3:05 AM
    Moderator
  • I think you misunderstood my question so I will rephrase it.

    Should I create one TFS project for all my applications and place each application into a "ProductFamilyN" folder inside my TFS project?

    Someone else said it should be done like this, he said each team/group should have one TFS project where they keep all their applications. Sometimes, but rarely, will they create additional TFS projects.

    I was under the impression that if I migrate from Subversion to TFS, I should create one TFS project for each Subversion repository. 


    chuckdawit

    Friday, September 21, 2012 4:23 AM
  • Hi Chuckdawit, 

    Thanks for your post.

    In TFS 2010, there has the Team Project Collection concept, it’s a collection of Team Projects.

    If your teams/groups can have their own Team Project Collections, I suggest you create Team Project Collection for each team/group, under each Team Project Collection, the team/group can create one or more Team Projects to store the applications.

    If you only can create one Team Project Collection for your teams/groups, I suggest each of your team/group has their own Team Project(s), then the team/group can store all theirs applications in one Team Project or several Team Projects.  


    John Qiao [MSFT]
    MSDN Community Support | Feedback to us

    Friday, September 21, 2012 6:54 AM
    Moderator
  • Hi John,

    Thanks for the response. What decisions do I make when determining whether to create multiple team projects or place all my groups applications into one team project? I don't think we have the ability to create new team collections and I think other teams will be using the same team collection folder, so in that case I am going to assume we will create one or just a couple of team projects to keep all our applications. Now, what decisions would I make if I thought we needed a new team project? Currently my group has about 19 applciations (WPF, Asp, libs, etc) the only confusion I have, if I don't put everything into one team project, is how I would link up one team project with another if our scrum needed to modify an application in one team project and a library in another team project?

    Would the best option to just be putting all our applications in one team project in this case, like in my original picture above where the "productfamily1" folder is a single application?


    chuckdawit


    • Edited by witdaj Friday, September 21, 2012 6:15 PM
    Friday, September 21, 2012 6:14 PM
  • I'm not sure that I understand what you mean with "product family", but if you have an application that consists of WPF, business layer in C#, database code in SQL, SSRS reports and whatnots, the entire application should reside in a single folder (which is likely to have subfolders), so that when you branch, you branch all at a time.

    The application may use a DLL which developed and maintain separately, and maybe shared by other applications. The source for that DLL should be in its own team project, but you may check in the DLL in the application project, to make easier to build.

    I may be misunderstanding you, but I get the impression that different technologies (WPF, ASP etc) should be in different Team Project, even if they are part of the same application. That seems like a very bad idea to me.


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
    Friday, September 21, 2012 9:34 PM
  • Erland,

    Here is a question to you. What if you have two team projects. One is a web site and the second is a library that other applications use, including the web site in its own team project.

    Now, when you go through a scrum planning meeting for the web site and see that you will need to make changes to the library in a different team project how do you handle the work items? They couldn't go into the web site backlog and if you create them in the library team project they will be disconnected from the web site team project and you would be in a different backlog with a different iteration all together.

    Without keeping both the library and the website in the same team project how would you link the two together so that you can create user stories and work on both applications from the same backlog?

    From reading through the TFS 2010 book by Wrox its seems like you would want to put all your teams applications into a single team project in TFS and seperate them by "areas" and "iterations". Given you have a small team < 50 and you work on different applications simultaneously.


    chuckdawit



    • Edited by witdaj Friday, September 21, 2012 10:03 PM
    Friday, September 21, 2012 10:00 PM
  • Well, I'm an SQL guy so I don't have Team Projects with web sites:-) Nor can you accuse for spending too much time in scrum meetings; I try to avoid meetings as much as possible. And the only time I have heard anything about Scrum was when I attended a TFS class, but I was only interested in the version-control parts.

    Then again, I have enough experience of system development to have a general opinion. If you have applications A, B, C and D that all use library L, and you are working with A and see that you need changes in L, you need to talk with the person(s) who own L and they will have to plan the changes, which includes ensuring that none of the changes affects B, C, and D. Then they will implement and release the changes so that you can use them.

    Obviously, this model can be slow, since the library owner may be short on resources. An alternative in this case is that you incorporate the library in your project, and later backport the improvements to the library. But in the long run this will create more work. Not the least if you never do the backport.

    If you are a small group of people that own applications and the library, the distinctions get blurred. It can still be a good idea to adhere to this model, because in the long run your applications can uphold a higher level of quality. And at least there should not be any resource problems.

    From reading through the TFS 2010 book by Wrox its seems like you would want to put all your teams applications into a single team project in TFS and seperate them by "areas" and "iterations". Given you have a small team < 50 and you work on different applications simultaneously.

    Not really. First of all, what I say above is a discussion on general level without any specific version-control system in mind.

    My post was sparked by the fact that you seemed to be considering to have different team projects for different technologies, but maybe I was just misreading you.

    I can't say how you should organise your applications, because I don't know them. In the shop where I spend most of the time, about everything is one single team project (if we forget that we still have some stuff in SourceSafe, as we have not completed the transition yet). There are however some components that are seen as "general" that are in a separate team project collection. But here we are talking about one big application, and the idea of splitting it up in different team projects is just lunacy.

    I think for you one decisive factor for you is what release cycle you have for your applications. If A, B, C and D are always released in parallel, you could stick all under a single project together with the library. But if they are released independently, they should also be managed independently, and in this case you also need to have a strict regime for your library, so that application in a an early stage goes and changes the library and break app B which is planned to release next week.


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
    Saturday, September 22, 2012 10:23 AM
  • Hi Chuckdawit,

    I would say that there is no perfect solution to your problem. It is more a matter of taste and what will fit the needs of your company.

    Putting everything into one team project will give you the benefit of keeping one backlog across all applications, libraries etc. But it will make your area and iteration paths more complex and possible access restrictions on the code will have to be handled on a "deeper level".

    Putting each application, shared library and so on into a separate team project will make it much easier to manage access to that code and workitems within the team project. Basically making it easy if a team "owns" a specific application or code base. But at the same time, making changes in multiple team projects will give you the problem of keeping track of work items across the team projects.

    I have also seen a sort of mix of these two options where a team project is created for each application, library etc and code is checked into these team projects. Then, for each project started at the company a new Team project is created in TFS using a project template matching the dev process used in that project (CMMI, Scrum etc) but no source code repository is created for these projects. Code changes are made in whatever team project the code is located and when code is checked in you associate the change to a work item in the "project project" (I hope that makes sense). This aproach breaks some of the reports you get out of the box.

    I'd say thet neither approach is perfect, you will run into issues no matter what. Sit down and have a look at how you work (or would like to work) most of the time and chose whatever approach fits best. Maybe 90% of the time it will work just fine and the other 10% will include some pain. At least the numbers wont be reversed. With some adjustments and customization maybe these 10% will shrink.

    Finally, I would not put this down as a shortcoming of TFS. I have so far not seen a tool that simply solves this problem. If anyone has, I would be very happy if they told me about it :)


    JESPER FERNSTRÖM
    Transcendent Group

    Wednesday, September 26, 2012 11:59 AM