Meilleur moyen: restructurer une solution Team Foundation Server (TFS) existante

Dans mon département, nous développons plusieurs AddOns plus petits pour un serveur de communication unifié. Pour le contrôle de version et le développement distribué, nous utilisons un Team Foundation Server 2012.

Mais: il n'y a qu'une seule grande solution TFS pour toutes nos applications et bibliothèques:

Solution principale
- Applications
  - App 1
  - App 2
  - App 3
- Externes
- Bibliothèques
  - Lib 1
  - Lib 2
- Outils

Le chemin "Application" contient toutes les applications principales. Ceux-ci ne dépendent pas les uns des autres, mais ils dépendent des projets des bibliothèques et des externes.

Le chemin "Externals" contient des DLL externes référencées dans nos applications et bibliothèques.

Le chemin des bibliothèques contient des bibliothèques couramment utilisées (modèles d'interface utilisateur, classes d'assistance, etc.). Ils ne dépendent pas les uns des autres et sont référencés dans les projets Bibliothèques et Outils.

Le chemin des outils contient des programmes d'aide tels que des assistants de configuration, des services Web de mise à jour, etc.

Maintenant, il y a quelques points majeurs pour lesquels je voudrais changer cette structure:

Nous ne pouvons pas utiliser de versions de serveur.
Il est inconfortable de gérer la gestion de mêlée TFS avec des sprints, des obstacles, etc. avec une structure de solution comme celle-ci.
Chaque développeur a toujours accès à tous les projets de la solution.
Une version complète dure trop longtemps si l'on frappe accidentellement [F6] dans Visual Studio ...

Que changeriez-vous dans cette solution? Comment diviseriez-vous ces projets en solutions plus petites, comment ces solutions devraient-elles être structurées?

Ma première approche serait de créer un projet TFS pour chaque application, bibliothèque et outil. Mais comment puis-je m'assurer que, par exemple, l'App 2 contient toujours la dernière version de Lib 1? Dois-je surveiller les modifications sur Lib 1 et mettre à jour l'App 2 manuellement dès que la Lib change? Ou puis-je en quelque sorte forcer Visual Studio à toujours utiliser la dernière version d'un projet externe?

Edit: Sur le TFS, il n'y a qu'une seule collection de projets d'équipe TFS, contenant un projet d'équipe TFS. Le projet d'équipe contient une grande solution Visual Studio, qui contient plusieurs dossiers contenant (voir la structure ci-dessus), chacun contenant plusieurs projets VS.

Ma question est maintenant, comment réorganiseriez-vous:

Projets de l'équipe TFS
Les projets VS

project-management team-foundation-server projects-and-solutions

— dhh
source

Lorsque vous dites "une grande solution TFS", parlez-vous d'une collection de projets d'équipe TFS, ou d'un projet d'équipe TFS, ou d'une solution Visual Studio?

— Zugbo

Comme l'a dit Zugbo, je pense que vous devez obtenir la bonne terminologie avant que quiconque puisse aider à répondre à cela, car vous semblez mélanger les projets d'équipe TFS avec les solutions Visual Studio. Vous pouvez avoir un seul projet d'équipe avec plusieurs solutions.

— Tom Robinson

Désolé d'avoir fourni trop peu de détails. Je vais modifier ma question initiale.

— dhh

Tenez-vous en à un projet d'équipe TFS, en avoir plusieurs devient une douleur lorsque vous essayez de mettre à niveau et a certaines limites lorsqu'il s'agit de traverser des éléments de travail de projet d'équipe. Au lieu de cela, vous devriez faire un usage intensif des zones et des itérations.

Divisez votre solution VS en plusieurs solutions, une par application principale. Cela accélérera beaucoup les builds locaux, ainsi que le serveur de build.

TFS2012 a un nouveau concept appelé Teams, crée une équipe par application et définit des itérations et des backlogs par défaut pour chacune. De cette façon, vous pouvez gérer le backlog pour chacun, ou afficher l'équipe racine pour voir un backlog cumulé. Ensuite, vous pouvez gérer les sprints soit au niveau d'une application, soit globalement selon ce qui vous convient.

Créez des packages NuGet pour toutes les bibliothèques référencées tierces qui n'en ont pas déjà. Stockez-les dans un référentiel privé (dossier partagé Windows) et activez la fonctionnalité de restauration de package pour NuGet en cliquant avec le bouton droit sur chaque solution et en l'activant (autorisez également la restauration de package à télécharger des packages dans les paramètres vs).

Si vous avez des bibliothèques internes partagées, créez également des packages NuGet pour eux et créez une solution vs contenant uniquement cette bibliothèque. Ajoutez une commande post build pour créer le package nuget, ou étendez votre modèle de build tfs pour le faire (il existe un certain nombre de modèles qui le font déjà).

— Betty
source

+1 - j'aimerais pouvoir faire plus. Lier la structure du référentiel à la structure de l'application est une recette pour des problèmes à mesure que la structure de l'application change. Laissez la séparation «douce» des fichiers de solution, des zones et des itérations servir de limites et partager ce qui a du sens à partager.

— Telastyn