Fusionando proyectos de equipo

Question

En nuestro proyecto actual tenemos cuatro Proyectos de equipo TFS2010 diferentes en la misma Colección de proyectos de equipo. La razón de esto es que las diferentes partes del proyecto querían usar diferentes plantillas de proyecto de equipo (CMMI vs Agile).

Todos los proyectos ahora usan la misma plantilla. Por lo tanto, ahora hemos llegado a la conclusión de que sería mejor fusionar los proyectos en un solo proyecto de equipo. Esto plantea varias preguntas:

1. ¿Es posible/factible utilizar uno de los proyectos existentes como proyecto objetivo para los otros tres?
2. ¿Cómo movemos nuestros elementos de trabajo existentes en el nuevo proyecto mientras mantenemos nuestro árbol de área? Esperamos crear un área raíz para cada uno de nuestros proyectos de equipo existentes y mover todos los elementos/áreas de trabajo debajo de este nodo raíz.
3. Hoy tenemos enlaces de elementos de trabajo de proyectos de un equipo a otro. ¿Cómo mantenemos estos enlaces al fusionarnos?
4. ¿Cuál es la mejor práctica al mover el código fuente? Un enfoque claro es simplemente copiarlo a la nueva ubicación y bloquear y mantener los proyectos del antiguo equipo en caso de que necesitemos acceder a versiones anteriores del código. Pero, ¿es factible usar ramificaciones para esto, p. ¿ramificando todo el código existente al nuevo proyecto de equipo? ¿Qué tipo de problemas podría causar este enfoque?

Gracias por su ayuda!

Answer 1

Desafortunadamente, TFS 2010 no le permite fusionar proyectos de equipo.

Stucturing Team Projects y Team Project Collections es una de las decisiones estratégicas más importantes que se deben tomar antes de comenzar a utilizar TFS. Desafortunadamente, muchos de los clientes a los que ayudamos no hacen que la planificación inicial sea necesaria y no entienden algunas de las limitaciones de TFS para fusionar, mover, dividir, etc. proyectos de equipo antes de que comiencen a utilizar TFS: (

Cuando tenemos compromisos de consultoría donde los clientes desean consolidar sus proyectos de equipo, terminamos teniendo que hacer un gran trabajo manual para migrar los artefactos. Hemos creado algunas herramientas para ayudarnos con este proceso para los elementos de trabajo, pero en su mayor parte, es un trabajo tedioso de consultoría. Las utilidades de migración siempre terminan necesitando ser personalizadas para cada cliente, ya que generalmente tienen diferentes reglas comerciales para la forma en que desean migrar.

En última instancia, una "migración "no termina trayendo una Toda la información y terminas con algunos otros problemas como los sellos de fecha y hora son diferentes de lo que eran originalmente. (He oído que se refirió como un problema de compresión en el tiempo con las migraciones.)

Algunos pensamientos adicionales para cada una de sus preguntas originales:

1. Claro, usted podría utilizar teóricamente uno de los proyectos de los equipos existentes como el objetivo para la migración de los otros tres. Siempre que te guste el nombre del proyecto del equipo y no quieras rename the team project. :)
2. Aquí es donde hemos creado utilidades de migración de elementos de trabajo personalizados para ayudar a nuestros clientes de consultoría. Es probable que necesites hacer lo mismo.
3. Esto también es posible con una utilidad de migración de elementos de trabajo personalizados. Puede realizar un seguimiento de las asignaciones entre ID de elementos de trabajo anteriores y nuevos ID de artículos de trabajo y luego agregar los enlaces más tarde una vez que se hayan creado todos los elementos de trabajo nuevos en el proyecto de equipo de destino.
4. Eso depende de ti. Haría un "move" version control operation en el código fuente del proyecto antiguo del equipo al proyecto del nuevo equipo. Esto mantiene todo. Sin embargo, no eliminaría ninguno de los proyectos antiguos del equipo porque eso también provocaría la destrucción del historial de control de versiones.

No es la mejor historia para usted, pero espero que le ayude a planificar un poco.