Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>First, don't use multiple Team Project, this is a huge mistake that everybody make at the beginning. For the size of your team and what you develop: one Team Project is what you need.</p> <p>You use two Team Projects when there are two teams of completely different people, working on a completely different project, with a completely different methodology/process.</p> <p>With one Team Project you can still:</p> <ul> <li>Have many branches (related or not).</li> <li>Have the administration of Source Control at the tiniest level you need</li> <li>Split your project into sub categories (functional, technical, whatever you need) using the Area Path (which is a node tree) of Work Item. This way you can have one big product backlog or dedicated ones.</li> <li>Overall reports on your whole project or on specific area (still using Area Path, but in Reporting Services)</li> <li>Trust me on that, it's the best way to go and many many people (including me the first time) make the mistake to use multiple Team Project and have to paid the price thereafter. What you need is a good Source Control hierarchical structure and a good Area Path tree.</li> </ul> <p>Concerning Solutions:</p> <p>Having one solution per main component of your project is not a bad thing, developers can work on a dedicated subset of the project, to maximize the productivity and reduce the coupling between components.</p> <p>But you still can have one global solution that reference all your projects and that will be use whenever you need to make changes that impact all your project. Having a global solution is also an easy way to build your whole project painlessly.</p> <p>The issue here is <strong>about cross component references</strong>, if one component you develop (e.g. Application1) needs another component you develop (e.g. OurCompanyLibrary) then it creates a dependency between both and Application1 must reference "built assemblies" of OurCompanyLibrary. </p> <p>Which implies either:</p> <ol> <li><p>You must create a location somewhere in your source control to store the built assemblies of all the components that will be referenced by others. Maintain a Build Cycle to release everything respecting the right order.</p></li> <li><p>Take advantage of the new standard which is <a href="http://nuget.org">Nuget</a> and setup an in-house Nuget server (very easy to do) and build your own Nuget packages for the components that will be referenced by others.</p></li> <li><p>The easiest way to go is including all your dependencies developed in-house in the solution to make sure they are built when needed. It's easy to do but your Application1 project will include most of your VS Projects. I don't say it a good or bad way to go, it's your call. Sometime the easy way is the best one.</p></li> </ol> <p>Each way has its own pros/cons, and only you can decide which one is the best to go.</p>
    singulars
    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. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. COHow would you handle assembly versions. Our strategy is having a shared assembly info file per solution, so OurCompanyLibrary would have a different version than CommonLibrary and so on. Would you now only have one assembly version for the whole team project? I realize you could have different version numbers, but is that the best way to do it or is the best way to have one version number for the entire team project?
      singulars
    2. COIf your final product is monolithic then all the assemblies can share the same version number and this number will be used to differentiate two different versions of your product. Now suppose you develop two products (for instance two unrelated web sites) based on the same component (company's core/business assemblies), assembly versionning takes a different meaning here, because the two web sites may use different version of the core/business assemblies and you may have different development cycle for the three of them (core/business, site 1, site2). If everything is monolithic, don't bother.
      singulars
    3. COThanks for the advice. It's not monolithic. We have two different public facing websites that do not use the same business assemblies, but the intranet uses the same business assemblies as the public websites. I think I would have different versions for each of the web sites and libraries. How would you branch this sort of thing? Would I have a Main and Dev branch like normal and then a Release branch for each of the different websites?
      singulars
 

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