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

20

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.
git release-management builds branch Fabian Schmengler
fuente
44
Parece que, por un lado, usted dice que no necesita la rama DEV, pero luego explica por qué realmente la necesita. Sería muy difícil fusionar las ramas de características que viven durante semanas después de divergir durante tanto tiempo. ¿ Seguro que quieres acabar con DEV?
Dave Swersky
@DaveSwersky buena pregunta! No estoy seguro, es por eso que pregunto aquí :) Acerca de las ramas de características de larga duración: la dificultad de fusionar es un problema que ya existe y que simplemente se mudaría a otro lugar. Y con fusiones regulares desde la rama principal es factible. ¿Cómo sería más difícil si la rama principal es maestra?
Fabian Schmengler
Las sucursales de larga duración siempre serán un desafío, aunque tal vez sea más un desafío fusionarse para dominar que para una sucursal DEV. La solución a ese problema puede ser separar mejor el trabajo para mantener esas ramas de corta duración. Si puede evitar que las ramas de temas / características vivan más de 24-48 horas, es posible que tenga más suerte eliminando el DEV.
Dave Swersky
1
@FabianSchmengler ¿Cuál es la verdadera razón por la que desea eliminar la rama de desarrollo? Realmente parece que lo necesitas para los casos en que las cosas no salen según lo planeado.
avi
llámelo maestro o desarrollo o lo que quiera, necesitará una rama de integración si desea tener un CI real, o si lo delega a las ramas de características, solo será una integración externa de ellas contra la versión actual de forma aislada.
ᴳᵁᴵᴰᴼ

Respuestas:

6

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? :

ingrese la descripción de la imagen aquí

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)
Dan Cornilescu
fuente
Gracias por las sugerencias detalladas. Todavía no estoy seguro si las sucursales de lanzamiento son una buena idea fuera del desarrollo del producto, pero lo reconsideraré, podría tener sentido para este proyecto
Fabian Schmengler
También tiene la alternativa de implementación continua, que coloca el desarrollo en el mismo lugar con la producción (en lugar de impulsarlo o precederlo), pero para eso necesita un cambio de cultura (ya que implica abandonar todas las ramas de integración y características).
Dan Cornilescu
Reconozco ese diagrama :)
paul_h 01 de
11

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.

Jiri Klouda
fuente
5

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).

Evgeny
fuente
2

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/

paul_h
fuente