Conciliación de Git Flow y QA

Nuestro proyecto está utilizando gitflow como se detalla aquí. Mi pregunta es cómo encaja la garantía de calidad en esto.

Considera que tengo una twig principal y una twig hotifx. Una vez que se realiza la revisión, creo que QA debería hacer sus cosas en una versión de la revisión. Si no pasa, la revisión se actualiza con esta corrección. QA obtiene un lanzamiento nuevamente. Ahora, cuando la revisión RC atesting el control de calidad, el código se fusiona nuevamente con el maestro (no debería haber conflictos y solo una copy directa ya que el maestro no se cambia). La versión de producción se realiza desde master. Sin embargo, la preocupación es que QA no haya verificado esta versión. Han verificado una compilation de revisión.

¿Cómo conciliamos el maestro solo para el código de producción pero tenemos testings de QA en un código de producción lo suficientemente cercano? ¿Alguien tiene alguna experiencia con este escenario? No puedo ver nada que detalle cómo la evaluación de calidad y las testings se ajustan a Gitflow.

Gracias

¿Dónde encaja QA? Por todas partes.

Me sale tu problema: si quieres que el maestro esté siempre listo para lanzar, entonces debes asegurarte de que tu trabajo sea probado antes de unirte al maestro. Pero si no testing contra maestro, ¿qué pasa si la combinación de sus cambios y la de otra persona causa un problema? Y si haces ambas cosas, ¿no es mucho trabajo?

La solución IMO es una combinación de comprobaciones automáticas y esfuerzo de testing de expansión sobre hotfix branch & master en lugar de hacerlo en uno u otro. Asume que usted (como desarrollador) y yo (como probador) estamos trabajando muy estrechamente en el mismo equipo, en lugar de en equipos diferentes con una carga de sobrecarga burocrática y transferencias formales que nos impiden queueborar de manera efectiva.

La retroalimentación de un probador es más útil cuando la obtiene lo antes posible. Me complace probar el trabajo interino, porque si puedo evitar que alguien tenga que volver atrás y extraer un montón de cosas al encontrar problemas temprano, eso es genial, y también me permite aprender más sobre la function más temprano (construyendo mi mental model, datos de testing, ideas para verificaciones automáticas), así que no estoy tratando de ponerme al día cuando la compilation final esté list. Idealmente, le habría escrito algunas comprobaciones de aceptación automáticas mientras desarrollaba, para que pueda ejecutar esas y sus testings de unidad contra su sucursal y master sin mucho esfuerzo adicional. (En la práctica, no siempre consigo esto a time, pero cuando lo tengo funciona bien). Y también esperaría que, independientemente de las comprobaciones que tenga ejecutándose contra el maestro, también las ejecute contra su twig de revisión justo antes de comprometerse.

Si hay mucho trabajo pasando en la misma área de la aplicación, entonces me gustaría hacer al less una exploración rápida contra el maestro después de su fusión, posiblemente más si se trata de un área crítica. Nuestro package automatizado ha captado algunos problemas de regresión y no me gustaría estar sin él, pero tener la automation nunca es una buena razón para no pensar un poco acerca de los riesgos.

Este es un enfoque: hay muchos otros que pueden funcionar para usted, dependiendo de su entorno. Para un enfoque interesante que escuché recientemente, busque "Mejore el process tomando control" por Amy Phillips de Songkick, donde trasladaron algunos de sus esfuerzos de testing después del lanzamiento, con el argumento de que, oye, la producción es lo más cercano que puede llegar a un entorno de producción ¿no? Obviamente, esto requiere el uso de características, y puede no ser aceptable en algunos entornos, pero es un buen ejemplo de pensar lateralmente acerca de dónde tiene sentido poner su esfuerzo de testing.

Trataré de explicar cómo la QA se ajusta al Gitflow. Aquí va brevemente:

Todo depende de tu definición de "hecho" según lo acordado en tu equipo. En mi opinión, la definición de done solo involucra a los desarrolladores que trabajan en la característica, por lo tanto, se satisface cuando los desarrolladores finalizan su trabajo y la revisión por pares atesting que este trabajo se fusione en la twig principal (sea lo que sea).

El control de calidad debe activarse solo cuando se corte la twig de liberación (como se describe en gitflow).

Por lo tanto, los desarrolladores hacen su trabajo a partir de una acumulación de 3 elementos. Eso probablemente significa 3 twigs de function (no utilizo el término de revisión como en gitflow que está reservado para reparaciones de emergencia en problemas encontrados en la producción). Uno a la vez (probablemente en diferentes momentos) las twigs se combinan para dominar. Cuando todos se fusionan, se corta una twig candidata de lanzamiento y se genera un artefacto para que el equipo de QA lo ejecute y lo pruebe.

Al mismo time, el equipo puede desarrollar y fusionar otras características en la línea principal (principal). Cualquier problema encontrado en la aplicación se corrige en la twig candidata de lanzamiento y las correcciones se fusionan en la línea principal para que estén allí en la siguiente versión. Se le da una nueva versión a QA que incluye las correcciones y el ciclo continúa.

Cuando QA es feliz, se genera el artefacto de producción (fusiona la twig de liberación con la maestra y activa una construcción prod).

Ahora creo que le preocupa que las 2 versiones (una de la twig de hotfix y la de master) sean versiones diferentes. Esto es y no es verdad. Es cierto ya que los binarys probados por el QA son diferentes y no es cierto ya que los binarys contienen el mismo código. Eso es, por supuesto, asumiendo que ningún otro código entra en el maestro intermedio y que el process de compilation no actualiza los ensamblajes (vía maven o nuget automáticamente) a las versiones más nuevas.

Si su lugar de trabajo quiere que libere los mismos binarys que los verificados por QA, entonces necesita producir la versión de producción de la twig de revisión (o mediante el esquema de giflow la twig de publicación [los verdes en el diagtwig]). De lo contrario, deberías estar bien para liberarlo del máster.

Extendí el model de ramificación de git flow de Vincent Driessen para include twigs que representan los entornos TEST, QA y PRD.

En lugar de dejar que MASTER contenga el último código en producción, elijo dejar que MASTER por defecto apunte a la última versión en QA. Luego, la implementación en PRD es solo una promoción de un candidato de lanzamiento que ya está en control de calidad para PRD.

Ahora puede hacer las revisiones en la versión de control de calidad, que probablemente ocurrirá más que en las revisiones para la versión de producción. Aún es posible realizar una revisión para la producción reiniciando la twig maestra a la versión en producción que desea corregir.

Con esto en mente, su caso se puede resolver con

1) restablecer la twig maestra a la versión de producción

2) crear una twig de revisión desde el maestro

3) aplicar la corrección a la twig de revisión

4) terminar la twig de revisión y fusionar en maestro y desarrollo

Ahora puede comstackr una versión candidata de la twig principal que se puede implementar en QA para probarla y luego promoverla en PRD cuando esté bien.

enter image description here