TFS – Sostenibilidad de las twigs en cascada

La guía de ramificación generalmente describe una twig "principal" inmortal, con funciones derivadas de Main, y fusionadas de nuevo a Main, y Releases ramificadas de Main, con otras twigs de Release como necesarias para Service Packs, RTM, etc. La guía con respecto a Main es a menudo simplificado a "sin basura en Main".

Estoy trabajando con un grupo que publica regularmente (tan a menudo como mensualmente) y en serie. Para ellos, parece innecesario devolver el trabajo a la sucursal Principal. Usan TFS 2010, su estructura de ramificación se ve de forma gráfica como esta:

enter image description here

Se crean construcciones diarias en una twig; eventualmente la twig va a producción. Todas las revisiones a una sucursal se aplican directamente a esa sucursal y, opcionalmente, se fusionan con las futuras sucursales en vuelo.

La estrategia de bifurcación de este grupo se ha descrito de forma perma- nente como el "Antipatín de twigs en cascada". ¿Pero es realmente así, dado que estas twigs se lanzan a la producción, y luego (por lo general) tienen un time bastante corto para vivir?

Esta práctica de sucursales en cascada en TFS es sostenible a largo ploop. Si no, ¿cuáles son los límites y cuándo (después de cuántas twigs) podrían ser alcanzados?

¿Hay alguna razón para NO "destruir" Main, R1, R2 (etc.) eventualmente, o hay un "gotcha" que evitará la destrucción y recuperación de espacio en el server SQL que aloja el repository de código fuente?

Las twigs en cascada pueden funcionar. Tampoco puedo pensar en ninguna razón técnica por la que destruir twigs muy antiguas (preferiblemente archivadas) tendría un impacto en las twigs en cascada más nuevas. Aquí hay algunos puntos a considerar:

  1. Los desarrolladores tienen que asignar una nueva twig a su área de trabajo después de cada lanzamiento.
  2. Los desarrolladores deben mover manualmente cualquier trabajo a una nueva bifurcación si no pudieron verificarlo antes de su lanzamiento (en comparación con solo registrarse en la misma twig Dev o Principal después del lanzamiento).
  3. Si tiene uno o más desarrolladores que trabajan en una sucursal secundaria de Rn y se toma la decisión de mover su trabajo a Rn + 1, se requerirá una fusión sin fundamento para evitar registrarse en la sucursal original de Rn.
  4. ASEGÚRESE DE BLOQUEAR DE FORMA SEGURA CADA RAMA después del lanzamiento. Todas esas twigs boostán el riesgo de que un desarrollador verifique accidentalmente un cambio en una twig liberada.
  5. Debe ajustar las definiciones de compilation y cualquier otro artefacto específico de ruta después de cada cascada. Si todo el desarrollo simplemente funciona desde Dev (o Main), entonces el espacio de trabajo primario y los artefactos de construcción / proyecto relacionados permanecen iguales a lo largo del time.
  6. ¿Cómo se trabaja en las características paralelas de forma aislada cuando no se sabe qué característica (es) se enviará en Rn? (Si tiene una twig principal, puede tener múltiples twigs de desarrollo de características secundarias desde Principal, luego combinar una twig de características solo cuando esté estable y list para fusionarse para enviarse en la próxima versión).

Creo que Jeff Levinson hizo una presentación que describió la evolución de las ramificaciones comenzando con una sola twig, luego una twig en cascada, luego Main + Release y un par de variaciones (mientras describía los pros y los contras de cada una). Consulte las prácticas de ramificación y fusión: Jeff Levinson (video de Teched 2010) (o PPT de ramificación y fusión relacionado).

¡Disfrutar! -Zephan

Intereting Posts