Recientemente, migramos casi todo el código fuente de mi empresa a una única solución.
¿Por qué?
Originalmente, teníamos docenas de soluciones. Algunos proyectos de una solución reutilizaron proyectos de otra, y a nadie le importó usar un administrador de paquetes. El día que cambie sustancialmente un proyecto que se usa en casi todas partes, espere horas y horas de trabajo perdido para toda la empresa durante los próximos días o semanas. La peor parte es que ni siquiera puedes saber qué se vería afectado exactamente por el cambio.
Fusionar todo el código en una solución era una alternativa. Funciona bien por el momento, y las dependencias ahora son fáciles de seguir. ¿Desea modificar un método pero también realizar un seguimiento de las repercusiones que este cambio puede tener en cualquier parte de la base del código? Visual Studio puede hacer eso con facilidad. Para mí es un éxito.
La integración continua ahora también es más fácil. Una solución para compilar e implementar. Casi nada que configurar.
¿Es escalable?
En cuanto al rendimiento, Visual Studio me sorprendió mucho . Pensé que comenzaría a llorar con una solución con, digamos, 50 proyectos. Hoy, hay más de 200 proyectos; Visual Studio parecía ser lo suficientemente escalable como para administrarlos como si solo hubiera 20 de ellos. Sí, hay cosas que llevan tiempo. Si vuelve a compilar cada proyecto, con contratos de código, análisis de código habilitado de forma predeterminada, etc., espere que tarde un tiempo. Pero nadie esperaría compilar 200 proyectos tan rápido como 10, y por cierto, no debería: esta es la función del servidor de integración continua. El tiempo de inicio (arranque en frío, luego cargar la solución) es impresionantemente rápido ; tal vez no sea tan rápido como con 10 proyectos, pero sigue siendo muy aceptable (menos de 20 segundos en una máquina comprada hace más de cinco años).
Para ir aún más lejos, descargar proyectos sistemáticamente es una buena idea (y realmente fácil cuando los proyectos se organizan en directorios dentro de la solución). Si alguien trabaja en algo que requiere la carga de solo tres proyectos, no es necesario cargar los 200 proyectos (a menos, por supuesto, que las dependencias puedan verse afectadas).
El control de versiones también funciona como se esperaba (estoy usando un servidor SVN, si es importante). No he trabajado en un entorno real concurrente, con, digamos, docenas de desarrolladores que frecuentemente cometen código, pero me imagino que esto no tendría demasiados problemas. Solo tenga cuidado con los casos en que muchos desarrolladores agregan nuevos proyectos al mismo tiempo: fusionar el archivo .sln no es lo más fácil de hacer.
Conclusión
Si tuviera que elegir la decisión nuevamente:
Todavía migraría todo a una única solución. Esto reduce enormemente el dolor de las dependencias rotas, y este beneficio solo vale totalmente la pena. Tener un lugar centralizado para todo el código también es una buena idea; Esto hace posible, por ejemplo, buscar algo dentro de Visual Studio. También puedo trabajar en dos proyectos débilmente relacionados, y todavía tengo una sola ventana de Visual Studio abierta.
También estudiaría un poco más NuGet y la capacidad de alojar un servidor NuGet privado. Administrar las dependencias a través de NuGet puede resolver algunos de los problemas cuando no desea fusionar algunos proyectos en la solución común. Personalmente, no tenía tales casos, pero imagino que otras compañías podrían tenerlos.
Finalmente, invertir en un SSD para cada desarrollador puede hacer una gran diferencia. Pero no es necesario, y en mi caso, la base del código todavía está almacenada en un disco duro normal.