TFS 2010 - comment les solutions VS avec bibliothèques partagées doivent-elles être mises en correspondance dans des «projets d'équipe»?

Question

Je suis nouveau sur TFS (et contrôle de source de style branche/fusion). J'ai lu le Guide de branchement de TFS pour 2010, mais je suis en train de me déconnecter de la façon dont mes solutions devraient être mappées au contrôle de source. Je pense que mon principal problème est de savoir comment comprendre le meilleur placement des bibliothèques de classes partagées entre les solutions.

Notre environnement est le secteur d'activité avec environ une douzaine d'applications Web distinctes et environ une demi-douzaine de bibliothèques de classes partagées entre les applications Web. Nos solutions comprennent généralement l'une des applications Web, le projet de test unitaire, les projets de bibliothèque de classes de support et toutes les références d'assemblage tierces.

donc deux solutions représentatives ressembleraient:

SOLUTION A
- WebApp11 Projet
- Projet WebApp11UnitTests
- Projet ClassLib11
- Projet ClassLib22
- ClassLib33 Projet
- bin \ *. dll

SOLUTION B
- Projet WebApp22
- Projet WebApp22UnitTests
- Projet ClassLib11
- Projet ClassLib22
- Projet ClassLib44
- Projet ClassLib55
-. Bin \ * dll

Comment concevoir ceux-ci en TFS? Créons-nous un projet d'équipe pour chaque solution, de sorte que ClassLib11, par exemple, appartienne à TEAM SOLUTION A et à TEAM SOLUTION B?

Je pense que oui, de sorte que chaque projet d'équipe se compose de tout ce qui est requis pour être mis en production. Que se passe-t-il si nous utilisons deux fichiers de solutions différents, comme un fichier de grande taille contenant toutes les applications Web et toutes les bibliothèques de classes? Où se situe cette solution?

Answer 1

Nous conservons toutes nos applications de production (nous avons une suite d'applications qui se chevauchent considérablement) dans un seul projet TFS. Cela permet à tous d'être régis par les mêmes règles puisqu'ils sont, potentiellement, tous être modifiés par des personnes différentes tout le temps, mais une seule personne aura parfois/souvent des scénarios où ils sont intéressés par de nombreuses applications différentes ensemble.