¿Cuál es la “definición” de una característica terminada en Gitflow?

7

Esta es una pregunta del proceso de Gitflow. En toda la documentación (y diagramas) que he leído sobre Gitflow, siempre indican que una vez que se completa una característica, se vuelve a fusionar en la rama de desarrollo.

¿Pero lo que nunca encuentro definido en ninguna parte es cuál es la definición de "una característica terminada"? ¿Se supone que las pruebas (Control de calidad, Pruebas de aceptación del usuario, etc.) ocurren en la rama de la característica en sí misma, o se supone que un desarrollador debe fusionar sus cambios nuevamente en la rama de desarrollo tan pronto como determinen que su implementación está completa (pero antes de Aceptación QA / UAT)?

Lógicamente, esperaría que QA / UAT se produjera en la rama de la característica en sí misma por la sencilla razón de que, de lo contrario, un código de baja calidad podría ingresar a la rama de desarrollo y contaminar otras ramas de desarrollo.

Sin embargo, si ese es el caso, ¿eso significa que cada nueva característica se prueba independientemente de otras características, y solo una vez que todo se fusiona para desarrollar una prueba de regresión completa en múltiples características? ¿Deberían las pruebas de regresión completa solo ocurrir una vez que se crea una rama de lanzamiento?

    
pregunta Eric B. 05.10.2016 - 18:04

4 respuestas

7

La función se debe probar por sí misma antes de que se termine y se vuelve a combinar en la rama de desarrollo. Sin embargo, creo que depende de cada equipo que use gitflow para definir lo que significa acabado. Cada equipo debe determinar la cantidad de pruebas que se deben realizar en la rama de funciones en comparación con la cantidad de pruebas que se deben realizar después de que se fusionen nuevamente en la rama de desarrollo.

Se deben realizar pruebas tanto en la rama de características como en la rama de desarrollo. Es razonable suponer que la rama desarrollada se encuentra en un estado diferente al de cuando creó su rama de características. Eso significa que necesitará una nueva ronda de pruebas para la rama de desarrollo una vez que finalice la función.

Si prueba su función por separado de cualquier cambio realizado en la rama de desarrollo, entonces si hay un error después de finalizar la función, puede usar estos resultados de prueba para ayudar a enfocar dónde está depurando su código.

Realmente depende de usted y su equipo la cantidad de pruebas que se realicen en la rama de características. Pero debe realizar una prueba completa en la rama de desarrollo después de que su función se fusione con la rama de desarrollo. Eso puede hacer que usted y su equipo realicen menos pruebas, como no realizar una UAT completa y solo confiar en Pruebas unitarias para la rama de la característica, o podría significar alguna otra cantidad de pruebas.

    
respondido por el DFord 05.10.2016 - 18:23
4

Es cuando dejas de trabajar en ello. Vas a tener que presentar tus propios criterios. Con suerte, su decisión de detenerse es que cumplió con los requisitos o dejó de intentarlo. También tendrás que decidir cómo usar el sistema si hay requisitos adicionales o si han cambiado.

No sé lo suficiente sobre Gitflow para determinar si solo ofrecen una herramienta o si pretenden una metodología específica para administrar el desarrollo de software. La mayoría de los martillos no te dicen qué clavos golpear, qué tan duro o qué tan profundo.

    
respondido por el JeffO 05.10.2016 - 18:23
4

Los equipos tienen diferentes estándares para considerar las características "hechas", pero esta parte generalmente se considera que es cuando se realiza el desarrollador . Sin embargo, eso no significa que pierdas la calidad. En mi equipo, eso significa que ha pasado una revisión de código, tiene un 100% de cobertura de pruebas unitarias, tiene pruebas de integración automatizadas y todas esas pruebas están pasando.

La razón es que hay un costo para aislar una sucursal durante demasiado tiempo. Cuanto más tiempo pase antes de volver a unirse a develop , mayor será el riesgo de conflictos graves cuando lo haga. Además, tiene solicitudes de extracción más grandes que son más difíciles de revisar a fondo. La vida útil ideal de una rama de función no es más que unos pocos días.

Con varios equipos trabajando a esa velocidad, ese tiempo de ciclo es demasiado rápido para que el control de calidad lo maneje, a menos que tenga una organización de control de calidad anormalmente grande. Debe darles compilaciones desde una rama que agregue características como una cuestión de pragmatismo. En el modelo de gitflow, creo que generalmente es el release de sucursales.

    
respondido por el Karl Bielefeldt 06.10.2016 - 01:18
-1

Esta definición es, según lo recuerdo, de Jessica Kerr, no de git flow, pero una característica terminada es una para la cual el código se ha eliminado permanentemente del entorno de producción. Como dice Kerr , una vez que haya dejado de ser útil y se haya eliminado, "nadie lo hará Alguna vez te llamo y te lo pregunto de nuevo ".

    
respondido por el bdsl 15.07.2018 - 20:58

Lea otras preguntas en las etiquetas