Tengo dos respuestas: qué hacemos y qué sugiero para usted.
Para nosotros, tenemos un conjunto de aplicaciones web que tienen MUCHOS componentes compartidos. Como tal, aunque se trata de aproximadamente 50 ensamblajes diferentes (proyectos VS) y 5-10 soluciones (dependiendo de cómo se mire), existe una superposición muy significativa entre todos ellos, lo que significa que queremos utilizar la fusión TFS por desarrollador en vez de que ramificar y fusionar esos recursos superpuestos. Como tal, en realidad guardamos todo esto en un solo proyecto TFS. Así es como hemos creado nuestra (nombres cambiados para dar sentido a usted):
"Official Projects" (Collection)
"Production Applications" (Project)
"Technology Proof of Concepts" (Project)
"Reference Projects" (Project) - this is a simple solution/projects using our architecture to make our architecture easier to understand as people join our team. Other reference apps will go here in the future.
"TFS Configuration" (Project)
"Playground" (Collection)
"John Doe" (Project)
"Jane Doe" (Project)
"Security Team" (Project)
"Production Test" (Project)
En nuestra configuración, tenemos un lugar para el código oficial de la compañía. Además, tenemos un área para que las personas se vayan de la risa sin tener miedo de arruinar nada mientras se pueden aprovechar los diversos beneficios relacionados con TFS.
Sin embargo, en su escenario, si estoy leyendo correctamente las líneas, sugeriría algo diferente. Mis suposiciones:
- Cada proyecto, aparte de tener algunos ensambles comunes (estoy pensando en el registro, la seguridad y otros ensambles de utilidad compartidos en toda la empresa), son proyectos no relacionados.
- Los conjuntos compartidos/comunes no se modifican con regularidad, por lo que puede utilizar referencias de DLL en lugar de referencias de proyectos, donde siempre está utilizando la última versión del código actualizada al minuto.
- (Asunción basada en TFS porque todavía estoy aprendiendo) Puede ramificarse en Proyectos de la misma Colección pero no puede ramificarse en Colecciones.
- Aparte de los conjuntos compartidos mencionados anteriormente, no se comparte ningún otro código entre equipos.
Así que con estas premisas, me gustaría ir con algo como esto:
"Common Resources" (Collection)
"Source" (Project) - everything goes here such as logging assemblies, security assemblies, etc.
"Version 1" (Project) - Branch as you "rev" your common assemblies so people have access to older versions.
"Version 2" (Project)
"Version 3" (Project"
etc.
"Team 1" (Collection)
"Project 1"
"Project 2"
"Project 3"
"Project 4"
"Project 5"
"Team 2" (Collection)
"Project 1"
"Project 2"
"Project 3"
"Team 3" (Collection)
"Project 1"
"Project 2"
etc.
Hacerlo de esta manera, se hace referencia a las asambleas comunes a través de referencias DLL. Usted, como equipo o desarrollador de un proyecto específico, puede decidir cuándo comienza a usar una versión más nueva de un ensamblaje común. Para hacerlo, simplemente obtenga la última versión de la rama de esa versión y luego agregue una referencia a ella. Si mi suposición n. ° 3 es incorrecta, entonces con suerte puedes hacer algo mejor que eso. De lo contrario, cada proyecto tiene su propio espacio (que puede contener más de una solución VS/proyecto, lo que es una buena idea) y su equipo tiene su propia colección para mantenerse separado de los otros equipos.
Sólo mi $ 0.02 vale ...
¿Se puede actualizar la estructura para indicar dónde se encuentran los archivos .sln y .csproj? Tengo un escenario donde tenemos una solución por artículo desplegable (Servicio de Windows o Aplicación web) y cada uno de estos puede depender de proyectos dentro de las soluciones (por ejemplo, un proyecto de interfaces en una solución a la que otro proyecto hace referencia en otra solución)) ¿Su sugerencia atiende esto?Actualmente copiamos manualmente ensamblajes distribuibles cuando construimos en una ubicación conocida y preconstruimos en otros proyectos que copiamos en las dependencias y hacemos referencia a la copia. – jamiebarrow