Maneje la ramificación de git para prueba y producción

git-flow

Question

Al trabajar con git (flow) y tener un entorno de etapa / prueba donde el cliente está haciendo sus revisiones de las cosas desarrolladas, ¿cuál es la mejor manera de manejar las características que no están aprobadas junto con las que sí lo están?

Considere el escenario en el que varios desarrolladores trabajan con diferentes características en un sprint o en un flujo de trabajo continuo. Las características deben ser revisadas por el cliente y para que las características puedan revisarse en el entorno de la etapa, deben fusionarse en la rama de desarrollo e implementarse.

Si, digamos, se han desarrollado dos características, consideradas realizadas por el equipo de desarrollo y llevadas a desarrollo. El cliente los revisa y aprueba UNO de ellos. Pero ahora el cliente quiere lanzar la característica aprobada a producción. La rama de desarrollo ahora está "contaminada" por un código de característica no aprobado que no se puede enviar a producción.

¿Cuál es la mejor manera de manejar tal escenario? Por supuesto, en realidad es más complejo. ¿La selección de cerezas es una solución o debería reconsiderarse el proceso general y el manejo de las sucursales?

Answer 1

Creo que la forma correcta aquí es:

• producción (...)
• maestro (la rama de desarrollo)
• característica123
• característica234
• característica345
• función [número]

Si puede, proporcione una característica [número] .example.com dominio a los clientes. Para que pueda mostrar todas las características antes de la fusión en la rama maestra. Si se rechaza una característica, nunca debe fusionarse en master. Si se acepta la función, debe fusionarse.

Una buena alternativa es también un dominio "provisional" donde implementar el código cuando sea necesario. Supongamos que su cliente necesita ver feature42, ... simplemente implemente feature42 en customer.example.com dominio customer.example.com .

¿Dónde desarrollar una nueva característica?

feature[number] branch

¿Dónde mostrar nueva función?

feature[number].example.com

¿Dónde ver el próximo código de sprint (maestro) en el trabajo?

next.example.com

o

master.example.com

¿Dónde ver el código de producción?

www.example.com

Answer 2

Ese problema (rama de desarrollo contaminada por ramas de características "no aprobadas pero ya integradas") es exactamente lo que describe a Raman Gupta en " Cómo crean los creadores de Git ".
( rocketraman/gitworkflow GitHub para este flujo de trabajo: rocketraman/gitworkflow )

En su caso (gitflow), necesitaría revertir la confirmación de fusión de las características no aprobadas antes de fusionar dev para liberar.

Pero el "gitworkflow" usa ramas efímeras, por oposición de gitflow:

GitFlow aboga por tener dos ramas eternas: master y develop

Ambos flujos de trabajo (gitflow o gitworkflow) usan ramas "feature" o "topic":

Las ramas temáticas son donde se está realizando todo el trabajo actual: una rama por problema, error o característica, y puede haber muchas ramas temáticas en desarrollo a la vez.

Un tema termina fusionado en la rama " next " en gitworkflow.
Sin embargo, una diferencia clave es que la next rama nunca se fusiona con master (en oposición a la rama eterna " develop " que está destinada a fusionarse con master / release en gitflow)

Ahora que el topic ha graduado al next , puede ser parte de una versión beta o una versión de aceptación. Por lo tanto, cada tema del próximo ahora puede someterse a una segunda ronda de estabilización, que es exactamente el propósito de un entorno de prueba de lanzamiento / aceptación beta.

Sin embargo, tenga en cuenta que con gitworkflow, todavía no nos hemos comprometido (¡sin juego de palabras!) A tener este topic como parte de nuestro próximo lanzamiento a producción; todavía no se ha fusionado para master .
Esto es similar en concepto a la rama de release de GitFlow, pero mucho más flexible y potente, ya que master no tiene dependencias de la next , ni se fusiona en master (a diferencia de las ramas de GitFlow correspondientes que se develop y release ) .

Si el siguiente no se fusiona con master, ¿cómo gradúa una característica para la producción?

Una vez que un tema se juzga lo suficientemente estable como para lanzarlo, el tema se gradúa nuevamente y se fusiona para master (o quizás maint ), nuevamente con --no-ff para preservar la historia completa de la rama del tema.

¿Por qué es esto mejor?

Tenga en cuenta que en gitworkflow, el trabajo de desarrollo inestable y estable nunca se mezcla en la misma rama.

En contraste, con GitFlow tengo dos opciones:

1. Puedo probar mi tema de forma aislada en su propia rama, o
2. Puedo fusionarlo para desarrollarlo para probarlo.

Ninguna de las opciones es atractiva.

• El primero no ofrece una prueba real de la estabilidad de un tema cuando se implementa junto con otro trabajo en curso, y
• este último compromete el tema a desarrollar tal vez antes de que sea estable.

Sentido:

En resumen, en GitFlow siempre existe una tensión irresoluble entre el deseo de mantener el trabajo de desarrollo limpio y aislado en una rama temática, y la integración de ramas temáticas con otro trabajo al fusionarlas para desarrollarlas para hacerlas visibles y verificables y para verificar conflictos.
Gitworkflow permite alcanzar ambos objetivos sin sacrificar uno por el otro.