Se requiere sugerencia de desarrollo basado en troncal

Estaba buscando buenos resources en estrategias de bifurcación después de hacer una ramificación de funciones durante bastantes años y luchando con muchas twigs y uniendo pesadillas. Las twigs de características nos dieron un buen aislamiento en la administración de lanzamientos de una manera bastante granular sobre qué características deberían ir a la versión. Sin embargo, los problemas que planteaban (muchas twigs, conflictos de fusión) eran mucho más que los beneficios que brindaban.

Trabajamos con la database Oracle (con 5000 objects) en el back-end. También tenemos varios equipos trabajando en diferentes áreas del mismo producto. Estamos usando Visual Studio con TFS (sin DVCS).

Cuantas más twigs creamos, más instancias de database que necesitamos para proporcionar un aislamiento adecuado en las testings funcionales en esas twigs (cada twig, una instancia de db) que son otro set de problemas.

Estamos adoptando el scrum y estamos buscando un model de bifurcación que se adapte a nuestro ciclo de lanzamiento (4 veces al año) y comstack CI. Estamos planeando hacer 5 sprints regulares y 1 sprint de fortalecimiento para cada lanzamiento.

A partir de un model de ramificación de características, volvimos a trabajar nuestro model de ramificación a una ramificación muy simple como a continuación:

Modelo de ramificación

La twig de desarrollo funciona como nuestro "Troncal" (para desarrollo basado en troncales) y TODOS los desarrolladores (todos los equipos) se comprometen con esta twig (para publicación trimestral), los probadores están probando en esta twig y el server de CI (Jenkins) está construyendo esta twig diariamente . Solo necesitamos una PRINCIPAL limpia en cualquier momento por razones de security como "Única fuente de verdad para la última versión", que se utiliza con frecuencia por varias razones.

La twig de mantenimiento es nuestra twig de reparación de errores (hotfix) y se lanza varias veces durante el año (independientemente de la publicación trimestral). Preferimos no trabajar directamente en la twig principal ya que queremos tener una twig principal "limpia". No queremos permitir que el código vaya a Main sin realizar testings "manuales" / funcionales. Una vez que se realiza una versión de corrección de errores, el código se fusiona desde Mantenimiento -> Principal -> Desarrollo para integrar las correcciones de errores en Desarrollo.

Por lo general, no requerimos las "Sucursales de Liberación" como se sugiere en TBD ya que continuamente corregiremos las fallas en la twig de Mantenimiento, se liberará del Mantenimiento y luego fusionaremos los cambios a Principal (y luego a Desarrollo). Mantenemos solo "Último lanzamiento" y en caso de que se requiera un parche de Versión anterior, creamos una twig de versión anterior desde Etiquetas en Principal.

¿Hemos modificado el desarrollo basado en troncales hasta el punto de plantear problemas en el futuro? ¿Cuáles son tus sugerencias?

Referir:

http://paulhammant.com/2013/12/04/what_is_your_branching_model

http://paulhammant.com/2013/04/05/what-is-trunk-based-development/#comment-2765204723

Debes crear una twig de mantenimiento a partir de la label que se lanzó, solo si encuentras un error. En realidad, esa es una twig de lanzamiento, y debe ser nombrada para el lanzamiento. Di rel_1.1. Para cuando hayas liberado la versión 1.2 y esté claro que no vas a retroceder, elimina rel_1.1.