Récemment, nous avons migré presque tout le code source de mon entreprise dans une seule solution.
Pourquoi?
À l'origine, nous avions des dizaines de solutions. Certains projets d'une solution réutilisaient des projets d'une autre, et personne ne se souciait d'utiliser un gestionnaire de packages. Le jour où vous changez substantiellement un projet qui est utilisé presque partout, attendez-vous à des heures et des heures de travail perdu pour toute l'entreprise pour les prochains jours ou semaines. Le pire, c'est que vous ne pouvez même pas savoir exactement ce qui serait affecté par le changement.
La fusion de tout le code en une seule solution était une alternative. Cela fonctionne bien pour le moment, et les dépendances sont désormais faciles à suivre. Vous souhaitez modifier une méthode mais également suivre les répercussions que ce changement peut avoir n'importe où dans la base de code? Visual Studio peut le faire facilement. Pour moi, c'est un succès.
L'intégration continue est désormais aussi plus facile. Une solution à compiler et à déployer. Presque rien à configurer.
Est-il évolutif?
Côté performances, j'ai été très surpris par Visual Studio . Je pensais qu'il va commencer à pleurer avec une solution avec, disons, 50 projets. Aujourd'hui, il y a plus de 200 projets; Visual Studio semblait être suffisamment évolutif pour les gérer comme s'il n'y en avait que 20. Oui, il y a des choses qui prennent du temps. Si vous recompilez chaque projet, avec les contrats de code, l'analyse de code activée par défaut, etc., attendez-vous à ce que cela prenne un certain temps. Mais personne ne s'attendrait à compiler 200 projets aussi rapidement que 10, et en passant, vous ne devriez pas: c'est le rôle du serveur d'intégration continue. Le temps de démarrage (démarrage à froid, puis chargement de la solution) est incroyablement rapide ; peut-être pas aussi vite qu'avec 10 projets, mais tout de même très acceptable (moins de 20 secondes sur une machine achetée il y a plus de cinq ans).
Pour aller encore plus loin, le déchargement systématique des projets est une bonne idée (et très simple lorsque les projets sont organisés dans des répertoires de la solution). Si quelqu'un travaille sur quelque chose qui ne nécessite que le chargement de trois projets, il n'est pas nécessaire de charger les 200 projets (sauf, bien sûr, les dépendances peuvent être affectées).
Le contrôle de version fonctionne également comme prévu (j'utilise un serveur SVN, si cela est important). Je n'ai pas travaillé dans un véritable environnement simultané, avec, par exemple, des dizaines de développeurs qui commettent fréquemment du code, mais j'imagine que cela n'aurait pas trop de problèmes. Attention aux cas où de nombreux développeurs ajoutent de nouveaux projets en même temps: la fusion du fichier .sln n'est pas la chose la plus simple à faire.
Conclusion
Si je devais choisir à nouveau la décision:
Je migrerais toujours tout dans une seule solution. Cela réduit considérablement la douleur des dépendances brisées, et cet avantage à lui seul en vaut la peine. Avoir une place centralisée pour tout le code est également une bonne idée; cela permet, par exemple, de rechercher quelque chose dans Visual Studio. Je peux également travailler sur deux projets faiblement liés et avoir toujours une seule fenêtre Visual Studio ouverte.
J'étudierais également un peu plus NuGet et la possibilité d'héberger un serveur NuGet privé. La gestion des dépendances via NuGet peut résoudre certains des problèmes lorsque vous ne souhaitez pas fusionner quelques projets dans la solution commune. Personnellement, je n'avais pas de tels cas, mais j'imagine que d'autres entreprises pourraient en avoir.
Enfin, investir dans un SSD pour chaque développeur peut faire une énorme différence. Mais vous n'en avez pas besoin, et dans mon cas, la base de code est toujours stockée sur un disque dur ordinaire.