Estrategia de bifurcación de Git para código no publicado de larga ejecución

13

En nuestro equipo, además de las unidades de trabajo individuales (Historias), tenemos temas de trabajo de mayor duración (Epics). Múltiples historias hacen una epopeya.

Tradicionalmente, hemos tenido ramas de características para cada historia y las hemos fusionado para dominarlas cuando pasan el control de calidad. Sin embargo, nos gustaría comenzar a retrasar el lanzamiento de historias completadas en una Epic hasta que la Epic se considere "característica completa". Solo lanzaríamos estas funciones a producción cuando se cierre la totalidad de Epic. Además, tenemos un servidor de compilación nocturna: nos gustaría que todas las Historias cerradas (incluidas aquellas que son parte de Epics incompletas) se implementen en este servidor nocturno automáticamente.

¿Hay sugerencias sobre cómo administrar nuestro repositorio para lograr esto? He considerado la introducción de "ramas épicas", donde fusionaríamos historias cerradas con la rama épica relacionada en lugar de dirigirlas al maestro, pero mis preocupaciones son:

  • Me preocupan los conflictos de combinación que pueden surgir si las ramas épicas se mantienen abiertas por mucho tiempo
  • Las construcciones nocturnas requerirían unir todas las ramas épicas en una rama de "construcción nocturna". Nuevamente, pueden surgir conflictos de combinación, y esto se debe hacer automáticamente
pregunta Sitati 12.01.2016 - 13:43

3 respuestas

19

Sugerencia simple: no hagas eso.

Las ramas de git no son para bifurcaciones de larga duración del código, como se explica aquí y enlace . Las ramas se tratan mejor como cosas transitorias que se utilizan para organizar las confirmaciones por parte de un desarrollador individual a nivel diario. Entonces, si tienen un nombre que corresponde a algo que a un administrador de proyectos (y mucho menos a un usuario final) le puede importar, está haciendo algo mal.

La práctica recomendada es utilizar la integración continua con funciones alternadas o rama-por-abstracción para asegurar que:

  • todo el código está integrado en todo momento (al menos todos los días, preferiblemente más a menudo)
  • lo que se implementa está bajo control explícito.
respondido por el soru 12.01.2016 - 14:24
1

Este es un problema difícil pero que muchas personas enfrentan. Prefiero usar la configuración de Gitflow como punto de partida.

Desarrollo - > Nuevas cosas que se están trabajando en
Maestro - > Cosas terminadas que necesitan pruebas Producción - > Material que ha sido publicado en producción.

En las funciones menores (más cortas) creo una rama desde el desarrollo, haga el trabajo allí y luego fusione la rama nuevamente con el desarrollo.

En las funciones principales (a largo plazo) creo una rama desde el desarrollo, creo ramas más pequeñas a partir de esa rama y luego vuelvo a la primera rama. Una vez que se ha completado la característica principal, se vuelve a la rama de desarrollo.

A intervalos regulares (depende del proyecto) fusiono el desarrollo con el maestro y comienza un ciclo de prueba. Si surgen algunos arreglos en las pruebas, se realizan en la rama maestra (la rama secundaria luego se fusiona). Y el desarrollo puede continuar en la rama maestra durante las pruebas.

En cualquier momento, el maestro debe fusionarse con el desarrollo, y el desarrollo debe fusionarse con cualquiera de sus subdivisiones a largo plazo.

el maestro siempre debe (en teoría) estar listo para la producción. El desarrollo siempre debe (en teoría) estar listo para la producción. La única razón por la que hay una diferencia es proporcionar un conjunto sólido de características para que los probadores las prueben.

Cuando está listo, una confirmación en el maestro que se prueba se fusiona con la producción y el despliegue en la producción se realiza desde esa rama. Los HOTFIX que deben hacerse en caso de emergencia pueden tener lugar en la rama de producción sin tener que fusionarse en el maestro (que puede tener muchos cambios sin probar).

Mi árbol normal se ve como

 LongTerm -> Development -> Master -> Production    
 LongTerm <- Development      |            |  
     |       Development -> Master         |  
 LongTerm <- Development -> Master         |  
             Development <- Master         |  
                            Master -> Production  

Es mi regla general que ningún cambio debe durar más de unas pocas horas. Si lo hace, entonces debe hacerse en cambios más pequeños. Si es una característica enorme (como una reescritura de la interfaz de usuario), eso va a largo plazo para que el desarrollo normal pueda continuar al mismo tiempo. Las sucursales a largo plazo normalmente son solo sucursales locales, mientras que Desarrollo, Máster y Producción son sucursales remotas. Las sucursales secundarias son también locales solamente. Esto mantiene el repositorio limpio para otros, sin perder la utilidad de git en un conjunto de características a largo plazo.

Me gustaría señalar, sin embargo, que la existencia de una rama a largo plazo es una cosa rara. Normalmente, todo mi trabajo está en desarrollo. Solo cuando tengo una característica (conjunto) que va a llevar tanto tiempo que necesito poder trabajar en cosas de desarrollo normal también, uso la rama de largo plazo. Si es solo un conjunto de cambios que deberían estar juntos, entonces no me fusiono para dominar hasta que no haya terminado.

    
respondido por el coteyr 12.01.2016 - 19:12
0

Creo que este es un problema bastante común y se reduce a elegir qué características incluir en una versión después de que las características hayan sido codificadas en lugar de antes.

por ejemplo.

Tengo las características A, B y C para v2 de mi producto. B y C están relacionados, no quiero lanzar B a menos que C también haya terminado.

Tengo tres desarrolladores trabajando todos al mismo tiempo en las funciones.

Tengo un set en la fecha de lanzamiento en piedra D

B se terminó y se fusionó, A se terminó y se fusionó. C se retrasó ... ¡¿qué hago ?!

No creo que exista una solución técnica para este problema. Desea lanzar una versión no probada del producto con solo la característica A incluida. A menos que combine y pruebe todas las combinaciones posibles de características, esto siempre será una posibilidad.

La solución es más humana. Te has perdido la fecha de lanzamiento y debes rechazarlo.

    
respondido por el Ewan 12.01.2016 - 14:51

Lea otras preguntas en las etiquetas