En mi departamento, estamos desarrollando varios complementos más pequeños para algún servidor de comunicación unificado. Para versiones y desarrollo distribuido, usamos Team Foundation Server 2012.
Pero: solo hay una gran solución TFS para todas nuestras aplicaciones y bibliotecas:
- Solución principal
- Aplicaciones
- Aplicación 1
- Aplicación 2
- Aplicación 3
- Exterioridad
- Bibliotecas
- Lib 1
- Lib 2
- Herramientas
- Aplicaciones
La ruta "Aplicación" contiene todas las aplicaciones principales. Esos no dependen el uno del otro, pero dependen de los proyectos de Bibliotecas y Externos.
La ruta "Externa" contiene algunas DLL externas a las que se hace referencia en nuestras Aplicaciones y Bibliotecas.
La ruta de Bibliotecas contiene libs de uso común (plantillas de IU, clases de ayuda, etc.). No dependen unos de otros y están referenciados en los proyectos de Bibliotecas y Herramientas.
La ruta de herramientas contiene algunos programas auxiliares como ayudantes de configuración, actualizar servicios web, etc.
Ahora, hay algunos puntos importantes por los que me gustaría cambiar esta estructura:
- No podemos usar compilaciones de servidor.
- Es incómodo administrar la gestión de scrum TFS con sprints, impedimentos, etc. con una estructura de solución como esa.
- Todos los desarrolladores siempre tienen acceso a todos los proyectos de la solución.
- Una compilación completa dura demasiado si accidentalmente se golpea [F6] en Visual Studio ...
¿Qué cambiarías en esta solución? ¿Cómo dividiría esos proyectos en soluciones más pequeñas? ¿Cómo deberían estructurarse esas soluciones?
Mi primer enfoque sería crear un proyecto TFS para cada aplicación, biblioteca y herramienta. Pero, ¿cómo puedo asegurarme de que, por ejemplo, la aplicación 2 siempre contenga la versión más reciente de Lib 1? ¿Tengo que monitorear los cambios en Lib 1 y actualizar la aplicación 2 manualmente tan pronto como cambie Lib? ¿O puedo de alguna manera forzar a Visual Studio a usar siempre la versión más reciente de un proyecto externo de alguna manera?
Editar: en TFS, solo hay una Colección de proyectos de equipo de TFS, que contiene un Proyecto de equipo de TFS. Team Project contiene una gran solución de Visual Studio, que contiene varias carpetas que contienen (consulte la estructura anterior) y cada una de ellas contiene múltiples proyectos VS.
Mi pregunta ahora es, ¿cómo reorganizarías:
- Los proyectos del equipo TFS
- Los proyectos VS
Respuestas:
Quédese con un proyecto de equipo TFS, tener múltiples se convierte en una molestia al intentar actualizar y tiene algunas limitaciones cuando se trata de elementos de trabajo de proyectos cruzados de equipo. En su lugar, debería estar haciendo un uso intensivo de Áreas e iteraciones.
Divida su solución VS en múltiples soluciones, una por aplicación principal. Esto acelerará mucho las compilaciones locales, así como el servidor de compilación.
TFS2012 tiene un nuevo concepto llamado Teams, crea un equipo por aplicación y establece iteraciones y trabajos pendientes predeterminados para cada uno. De esta manera, puede administrar el trabajo acumulado para cada uno o ver el equipo raíz para ver un trabajo acumulado acumulado. Luego puede administrar sprints a nivel de aplicación o en general, según lo que más le convenga.
Cree paquetes NuGet para todas las bibliotecas referenciadas de terceros que aún no tienen una. Almacénelos en un repositorio privado (carpeta compartida de Windows) y habilite la función de restauración de paquetes para NuGet haciendo clic con el botón derecho en cada solución y habilitándola (también permita que la restauración de paquetes descargue paquetes en configuraciones vs).
Si tiene alguna biblioteca interna compartida, cree paquetes NuGet para ellos también y cree una solución vs que contenga esa biblioteca. Agregue un comando post build para crear el paquete nuget, o extienda su plantilla de compilación tfs para hacerlo (hay una serie de plantillas que ya lo hacen).
fuente