Cómo deshacerse de la rama de desarrollo para un flujo Git simplificado

En un proyecto web desarrollado continuamente (no un producto) actualmente tenemos la siguiente estrategia de ramificación, basada aproximadamente en el flujo de git :

• desarrollar sucursal: última versión de trabajo
• rama maestra: versión que se lanzará / versión lanzada
• ramas de características: características en desarrollo
• ramas de revisión: correcciones de errores urgentes en la versión lanzada

El maestro es de solo lectura, actualizado a través de solicitudes de extracción de las ramas de desarrollo o revisión . Cada actualización da como resultado un candidato de versión que se construye e implementa en el sistema de preparación. Los candidatos de lanzamiento se implementan en producción después de la aprobación manual.

Las ramas de características se crean en función del desarrollo o de la última confirmación que se ha fusionado con el maestro. Se crea una solicitud de extracción de una rama de características para desarrollar, implementar en un sistema de prueba gratuito donde se ejecutan pruebas de integración y pruebas de aceptación (automática y manual). Cuando se prueba y revisa con éxito, el PR se fusiona, por lo que se convertirá en parte de la próxima versión (es decir, se fusionará de desarrollo a maestro).

Mi meta

Me gustaría simplificar esto y deshacerme de la rama de desarrollo. La rama de desarrollo tiene principalmente razones históricas y, dado que siempre es una versión probada con éxito, creo que no es necesario mantenerla separada del maestro. Eliminarlo también simplificará el proceso de lanzamiento porque ya no hay una fusión adicional.

Tengo las siguientes restricciones:

• los lanzamientos están programados y no deben automatizarse completamente
• Si bien las ramas de características suelen ser de corta duración, algunas permanecen sin fusionar durante varias semanas (por ejemplo, un rediseño), pero también deben probarse (actualmente, como solicitudes de extracción abiertas para desarrollar)
• a veces se debe lanzar una única función fuera de la versión normal, convirtiéndola efectivamente en una revisión. Con la estrategia actual, puedo volver a crear una rama de características y fusionarla directamente en master
• también sucede que necesitamos retener las funciones después de que las pruebas de aceptación con sistemas externos en la puesta en escena fallaron

Donde no estoy seguro acerca de la transición:

• Actualmente estoy creando solicitudes de extracción para probar y fusionar confirmaciones para lanzamientos. ¿Puedo unificar esto?
• cómo lidiar con las revisiones cuando el maestro está por delante de la última versión. ¿Debo compilar e implementar lanzamientos directamente desde las sucursales de revisión?
• ¿Existe una manera sensata de manejar las características que deberían excluirse de una versión después de que ya se hayan fusionado? ¿Es una rama de desarrollo separada realmente una ventaja para estos casos? La mayoría de las veces termino revertiendo y volviendo a revertir confirmaciones manualmente de todos modos.

En mi humilde opinión, los problemas que enfrenta son solo un efecto secundario de la mala estrategia de sucursal con la que comenzó: efectivamente está implementando un nuevo desarrollo develop(es decir, lo que converge hacia el futuro código de producción) a través del código de producción actualmaster . Esto lleva a requisitos y problemas contradictorios, ya que típicamente el código futuro difiere del actual:

• el nuevo desarrollo desestabiliza la producción: regresiones vistas después de fusionarse developenmaster
• estabilizar la producción ralentiza el desarrollo futuro: debe estabilizarse developpara que sea lo suficientemente bueno como para fusionarse enmaster

Dejar caer developno ayudará (mucho): no está eliminando el problema, solo está transfiriendo la developparte específica del problema master.

Un mejor enfoque sería mover la producción detrás del desarrollo actual / futuro, para evitar interferencias con el desarrollo para futuras versiones, como se ilustra en esta imagen de ¿Cuál es su modelo de ramificación? :

Tenga en cuenta que solo me estoy refiriendo a las ramas de lanzamiento en la imagen de arriba, no a lo que está sucediendo en el tronco.

¿Cómo funcionaría esto para usted?

• la developrama desaparece, como quisieras, absorbida enmaster
• la masterrama es su tronco, aquí es donde ocurre el desarrollo sin restricciones de velocidad ( nunca se fusionó con la producción).
• la producción es / son una o más releaseramas extraídas de una masteretiqueta / etiqueta que se considera lo suficientemente cercana a la calidad de la producción (si es necesario, se puede abordar una breve lista de elementos pendientes en esa rama). Estas ramas solo pueden recibir arreglos directos y / o arreglos seleccionados master, nunca se fusionan con masterotras ramas
• las revisiones son confirmaciones directas en releaseramas

Si un hotfix se aplica solo a una versión de producción pero no a la versión master, se compromete directamente con la releaserama. Si se aplica a ambos, generalmente se compromete a masterprimero y también a la releaserama.

Ahora mirando lo que entra master(que está más allá del punto donde releasese arranca la rama actual ), tiene 2 opciones:

• continúe con las ramas de características como lo hace hoy, excepto que se basarán master, no develop. Convertirlos en correcciones urgentes sigue siendo posible: solo tendría que volver a colocarlos en la releaserama correspondiente en lugar demaster
• cambie a una integración continua y obtenga sus beneficios (se puede hacer en cualquier momento en el futuro), incluso de manera progresiva: obtenga gradualmente cada vez menos ramas de características.

Si te gusta este enfoque, así es como llegas desde donde estás hoy:

• establecer una estrategia de nombres de lanzamiento:
  • no puede tener una rama de lanzamiento en curso con el mismo nombre
  • no puede (en realidad no debería) volver a crear o sincronizar una rama de lanzamiento de producción
• extraer una releaseXrama de masterinmediato, siguiendo esa estrategia de nomenclatura
• dejen de comprometerse develop, pronto irán directamente a master.
• fusionarse developenmaster
• instruir a los desarrolladores para que cambien sus espacios de trabajo en masterlugar de hacerlo develop.
• abierto masterpara commits
• elimine developsi lo desea (o déjelo permanentemente bloqueado / solo lectura para referencia)

Supongamos que elimina la rama maestra (puede cambiar el nombre de desarrollo a maestro para confundir a su equipo si lo desea más adelante) y simplemente use etiquetas para lanzamientos en las ramas de desarrollo o revisión. Sacaste una rama, pero la diferencia es solo un cambio en la sintaxis. Cambio por cambio de bien.

Ahora, digamos que realmente saca el desarrollo manteniendo la rama maestra bloqueada. Lo que sucederá es que la integración del código se ralentizará, vivirá más tiempo separada en ramas de características, especialmente cerca de las fechas de lanzamiento. Esto aumentará la dificultad de fusionarse cada vez y ralentizará el proceso.

Dentro de las restricciones que usted ha establecido, no veo ningún efecto positivo de hacer tal cambio. Requeriría relajar las restricciones, especialmente la primera.

Ya está compilando y probando código en cada una de las ramas de solicitud de extracción y corrección en caliente. Esto significa que, en conjunto, la suma de todas las ramas pendientes de solicitud de extracción es su developrama virtual .

Puede crear un sistema cuando en un entorno de prueba, varias solicitudes de extracción se seleccionan en una rama temporal que no se publica en el repositorio principal. Esta rama se utiliza para integrar un entorno de prueba que incluye mastery varias solicitudes de extracción adicionales, pero una vez que se realiza la prueba, esta rama ya no está disponible en ninguna parte.

Cuando crea una versión de master, generalmente crearía una etiqueta en esa versión. Las revisiones posteriores pueden usar esa etiqueta para crear una nueva rama de revisión a partir de la cual se realizará una implementación, aunque el borde de masterya esté adelante. En esta rama de revisión, probablemente también etiquete una versión menor y asegúrese de que los cambios se fusionaron master.

Eliminar características fusionadas de una versión es bastante difícil de hacer con git. El mejor mecanismo para esto sería usar git reverten el commit de fusión. Pero eso hace que sea casi imposible recuperar estas características / cambios, y la historia se vuelve confusa.

Una forma mucho mejor de manejar la separación para el despliegue de código y la liberación de funciones son los indicadores de funciones . Si sus desarrolladores pueden ocultar sus características detrás de algunas condiciones en el código mismo, puede implementar su código, pero desactivar la función. Este es un tema aparte, pero existe mucha información sobre esto (incluyendo preguntas y respuestas sobre devops.SE).

Bueno, @ dan-cornilescu lo dice bien para su problema particular, pero el caso más general para el desarrollo basado en troncales (mencionado en la entrega continua, Lean Enterprise y el manual DevOps) se hace aquí: https://trunkbaseddevelopment.com/