plugin - install git flow extension

¿Cómo debería trabajar Git Flow con QA probando tanto un lanzamiento como una nueva característica?

Question

Estamos utilizando Git Flow en nuestro último proyecto de iOS y estoy tratando de encontrar una forma de trabajar con QA para que puedan probar la última versión, así como probar una nueva característica, sin tener que preocuparme por los errores que se solucionaron. qué rama.

En la actualidad, han estado probando en la release/v1.0.1 , que tiene varios errores solucionados desde la release/v1.0 original release/v1.0 . Al mismo tiempo, he estado trabajando en una nueva característica que ha sido planificada para la versión v1.1, pero se desvió de la rama de develop al mismo tiempo que la release/v1.0.1 y, por lo tanto, no tiene ninguna de las correcciones de errores en ella.

Hoy, el departamento de control de calidad desea tomar mi nueva función para una prueba de manejo. Sin embargo, si les creo una compilación a partir de mi rama, ninguna de las correcciones de errores que han vuelto a probar y cerrar estarán allí. Por lo tanto, recibiré una gran cantidad de quejas y pánicos sobre los errores que se han vuelto a introducir ... ¡Lo que quiero evitar!

Entonces, ¿cuál es la mejor manera de hacer que prueben esto? Podría fusionar release/v1.0.1 en mi rama de funciones, pero luego debería asegurarme de no fusionar nuevamente con el develop antes de que se haya lanzado release/v1.0.1 ... Y supongo que hasta cierto punto, esto rompe el flujo de Git metodología. Podría crear una rama completamente nueva solo para las pruebas de control de calidad, que combina mi función con la release/v1.0.1 , pero ¿qué hago con los errores que encuentran en esta rama? ¿Dónde lo fusiono de nuevo después de la ronda de control de calidad?

Además de todo esto, tengo que considerar los números de compilación y los números de versión, para que tengan sentido. Actualmente, los números de versión son los que se utilizan para la publicación, y los números de compilación se incrementan con cada nueva compilación para el control de calidad. Sin embargo, si reciben compilaciones de dos ramas separadas, podría terminar con choques de números de compilación que podrían causar confusión.

¿Cuál sería la mejor manera de lidiar con estos problemas?

Answer 1

Me referiré a partes del primer diagrama de la página Git Flow de nvie.com a lo largo de mi respuesta; Para completar, he añadido una captura de pantalla a continuación.

Hoy, el departamento de control de calidad desea tomar mi nueva función para una prueba de manejo. Sin embargo, si les creo una compilación a partir de mi rama, ninguna de las correcciones de errores que han vuelto a probar y cerrar estarán allí. Por lo tanto, recibiré una gran cantidad de quejas y pánicos sobre los errores que se han vuelto a introducir ... ¡Lo que quiero evitar!

Entonces, ¿cuál es la mejor manera de hacer que prueben esto? Podría fusionar release/v1.0.1 en mi rama de funciones, pero luego debería asegurarme de no fusionar nuevamente con el desarrollo antes de que se haya lanzado release / v1.0.1 `...

No; no debe combinar una rama de lanzamiento directamente en una rama de entidad. De acuerdo con el modelo de Git Flow, debes (continuamente)

1. fusionar release/v.1.0.1 en la rama de develop ,
2. fusionar develop en sus ramas de función,

con el fin de traer cambios de estabilización desde la release/v.1.0.1 a sus ramas de características.

(Desafortunadamente, la imagen de arriba no muestra fusiones continuas de develop en feature , pero eso es lo que se supone que debes hacer).

Podría crear una rama completamente nueva solo para las pruebas de control de calidad, que combina mi función con la release/v1.0.1 [...]

Hay algo de ambigüedad, ahí. ¿Está sugiriendo fusionar la feature en release/v1.0.1 , o fusionar release/v1.0.1 en la feature ? No debe hacer lo primero, porque es demasiado tarde para que las nuevas funciones entren en la release/v.1.0.1 ; v1.0.1 enviarse con una versión futura, es decir, después de v1.0.1 . Lee la burbuja de la izquierda:

Y tampoco debes hacer lo segundo; Al menos, no directamente. Como se explicó anteriormente, para llevar los cambios de la release/v1.0.1 a la feature , primero debe combinar la release/v1.0.1 en el develop , y luego combinar la función de develop en la feature ; esto puede / debe suceder varias veces antes de que la feature esté lista para volver a integrarse en el develop .

Apéndice

Si sigues el modelo de Git Flow a la letra,

1. no debe tener dos o más ramas de liberación coexistentes, y
2. El control de calidad solo debe probar las ramas de liberación (también conocidas como estabilizadoras ).

Por lo tanto, si se supone que otras funciones deben ir a la v1.1 , aún no puede pedir a QA que revise sus nuevas funciones; Tienes que esperar hasta que se completen las otras características. Una vez que todas las funciones para v1.1 se hayan completado e integrado en el develop , cree una release/v1.1 (que se deriva de la cabeza de develop ); luego pida a QA que comience a probar / estabilizar esa rama.

Si, por otro lado, realmente no puede esperar a que se completen las otras funciones antes de pedir a QA que pruebe sus propias características nuevas, debe crear una rama de versión intermedia (llamada v1.0.2 , supongo) derivada de develop y Dígale a QA que pruebe la release/v1.0.2 . Una vez que se haya estabilizado en forma satisfactoria, fusionarlo en el master (y en el develop ).