Modelo de ramificación de TFS 2010 para una aplicación interna

Question

Esta no es una pregunta para la que no tengo ideas, sino que me gustaría presentar un modelo y ver si se aprueba o si alguien puede ver problemas con él o tiene mejores sugerencias. Dicen que es mejor elegir cuidadosamente su modelo de ramificación para evitar futuros dolores de cabeza.

Tenemos una aplicación interna con solo una versión (la última) lanzada a los clientes y básicamente hay 2 tipos de actividades de desarrollo: la actividad principal es trabajar para la próxima versión y generalmente incluye nuevas funciones y correcciones correctivas y está planeado, y el segundo que no está planeado y es de mantenimiento e incluye hotfixes de la versión actual en producción.

Después de una larga investigación, decidimos optar por un tronco Principal desde el cual ramificamos 2 ramas secundarias: Desarrollo y Mantenimiento (o Revisión ). Como se presenta en la guía, el desarrollo diario ocurriría en la rama Desarrollo desde donde hacemos la integración inversa (RI) cada vez que tenemos características listas para la próxima versión. Justo antes del lanzamiento, la integración inversa se detendrá y el código se estabilizará en la rama Principal . Después del lanzamiento de Main , habrá una integración hacia adelante (FI) de Main a Desarrollo y Mantenimiento . < / p>

Cualquier revisión ocurrirá en Mantenimiento solamente y dependiendo de la corrección (por ejemplo, si queremos retenerla en la base de código) haremos una RI en Principal y de ahí un FI a Desarrollo .

Ahora todo parece estar bien, al menos en papel, así que me gustaría escuchar las opiniones de los demás sobre este modelo.

Por ejemplo, también consideraríamos tener otra rama, Lanzamiento , donde la estabilización del código ocurre antes de un lanzamiento a producción (en lugar de trabajar directamente en Principal ) y por supuesto, lanzaremos desde aquí a producción y haremos un RI en Principal seguido de un FI para Desarrollo y Mantenimiento , pero no estamos ¿Está seguro de si esto traerá algún beneficio o simplemente aumentará la complejidad?

Y asumiendo que habrá funciones en Desarrollo que no estarán listas o no serán deseadas para la próxima versión, esto significa que tendremos que hacer una "selección selectiva" de los conjuntos de cambios relacionados a las funciones deseadas, pero eso no es demasiado bueno según los documentos. ¿Alguna sugerencia?

Una vez más, sé que no es una pregunta sencilla y directa, sino abierta, pero espero escuchar a alguien con una experiencia similar. Gracias de antemano por su atención.

Answer 1

¿Ha leído la documentación de la Guía de ramificación de TFS ALM Rangers?Lo que está proponiendo se parece mucho a su "Plan de rama estándar", aunque recomiendan tener una rama de lanzamiento y un "paquete de servicio" (muy similar a sus ramas de lanzamiento y mantenimiento anteriores).

http://vsarbranchingguide.codeplex.com/

He implementado el plan de ramificación estándar en algunos clientes y no he tenido ningún problema con él.Si planea adoptar flujos de trabajo simultáneos (equipos de funciones, etc.), la Guía de ramificación también tiene planes sólidos para eso.

Otra cosa a considerar podría ser un modelo escalonado en el que crea nuevas ramas de desarrollo en cada versión y congela la antigua como una versión.Esto evitaría las instancias reservadas, ya que solo puede realizar una revisión de la antigua y FI la corrección en la nueva rama de desarrollo si es necesario.También trabajé en este modelo y fue increíble.