Note that there are some explanatory texts on larger screens.

plurals
  1. POPros and cons of different strategies to managing shared resources in TFS 2012
    primarykey
    data
    text
    <p><strong>Background</strong></p> <p>According to the Visual Studio ALM Rangers, there are two major approaches to sharing resources (e.g. common libraries which are used in many separate products) in TFS 2012: </p> <ul> <li><em>Workspace mapping</em>, setting up workspaces so that they point to the appropriate version of each required library and product.</li> <li><em>Shared folders</em>, using branch/merge to get and update the shared resource</li> </ul> <p>At a glance, shared folders seems like the way to go, but a client that I am working with has experienced a lot of problems with that approach in Starteam, and is reluctant to try it again in TFS. I am currently in the process of assisting the client migrating from Starteam to TFS.</p> <p>I have listed pros and cons with each approach, but I am uncertain if I have missed something. </p> <p><em>Workspace mapping:</em></p> <ul> <li>Simple to setup and understand</li> <li>Easy to test a library change in several products</li> <li>Easy to get latest changes in a library, and to submit changes to a library</li> <li>No tracability, or at least less tracability, e.g. if a change in a library was introduced in Product A, how to track that change in Product B</li> <li>Changes in libraries may affect products in an uncontrolled manner</li> <li>Build gets more complicated</li> <li>Each user must set up his/her workspace individually (but there are workspace templates in TFS 2012 Power Tools)</li> </ul> <p><em>Folder mapping:</em></p> <ul> <li>Everything that is needed is configured in a given branch</li> <li>Isolation between products and branches</li> <li>Builds are simplified </li> <li>More control of changes</li> <li>Requires more disk space</li> <li>Requires more administration in the form of branching/merging and setup of branches</li> </ul> <p>One particular problem is how to test library changes in several products. As I understand that would require testing in product A, then reverse integrate to library and forward integrate to product B, then test that product and so on.</p> <p><strong>Conclusion, and final question</strong></p> <p>The client has successfully used something similar to workspace mapping in Starteam for 10 years, and plan to continue to use that approach in TFS. Although they have the problem to keep track of library changes that affects several products.</p> <p>They are afraid that folder sharing will get messy and complicated.</p> <p>My question is, have I missed something in my list above? Are there more reasons for why an organisation not should use workspace mapping, or for why they should use folder sharing.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload