¿Dónde debe el equipo de control de calidad hacer las pruebas en el modelo de ramificación de Gitflow?

Somos un gran equipo (10-12 desarrolladores y 4 qa) trabajando en múltiples proyectos con el mismo repositorio git. Es un servicio web de back-end basado en arranque de primavera. Estamos buscando una buena estrategia de ramificación e implementación de git. También tenemos un equipo de control de calidad que se asegura de que nuestras funciones funcionen como se espera (hasta cierto punto, sin errores).

Después de leer algunos artículos, tuve la sensación de que el modelo Gitflow funcionaría bien para nosotros. Aquí viene mi pregunta.

¿Dónde debe nuestro equipo de control de calidad probar nuestras características?

1. si prueban en la rama de características, donde generarán errores y el desarrollador lo corregirá y una vez que pase la prueba de control de calidad, nos uniremos para desarrollar. y QA volverá a hacer las pruebas de integración en la rama de desarrollo.
2. Deberíamos fusionar todas las características (después de las pruebas unitarias y las pruebas básicas del desarrollador) para desarrollar la rama y dejar que la prueba qa desde allí. correcciones y pruebas sucederán también en desarrollo.

Tengo curiosidad por saber qué enfoque funcionó bien para los demás.

El control de calidad probablemente debería estar probando dos veces.

La primera prueba debe estar relacionada con los cambios específicos y realizarse en la rama de características. Esto permite que el control de calidad pruebe los cambios específicos y vea que el cambio particular se complete según lo especificado y se comporte como se esperaba. También les ofrece una vista previa temprana para la segunda ronda de pruebas, que es lo que realmente importa para el control de calidad.

Desde mi experiencia en diversos entornos regulados, la segunda prueba debe hacerse en una etiqueta en la rama de desarrollo que corresponde a una versión, o la rama de la versión, o tal vez la rama maestra. Antes de un lanzamiento, QA debería probar el código completo y completo que se implementará antes de que se implemente y usted debe poder afirmar que lo que haya probado QA es exactamente idéntico a lo que se implementa en producción. Preferiría que después de un congelamiento de código, se aplicara una etiqueta a la rama de lanzamiento y el control de calidad lo probaría. Los cambios se realizarían en una rama de desarrollo, se verificaría puntualmente y luego se volvería a probar en una nueva etiqueta en la rama de lanzamiento. Estas etiquetas en la rama de lanzamiento corresponderían a los candidatos de lanzamiento.

Estoy haciendo algunas suposiciones aquí. Primero, tiene una cobertura de prueba bastante decente basada en el desarrollador. Idealmente, esto sería una unidad automatizada y pruebas de integración que los desarrolladores ejecutan y lo hacen antes de enviar cualquier código en cualquier sucursal a QA. Los desarrolladores también pueden querer hacer algunas pruebas exploratorias alrededor de la interfaz de usuario para asegurarse de que las cosas se vean bien antes de las pruebas de control de calidad. En segundo lugar, existe una buena coordinación entre el desarrollo y el control de calidad para planificar los cambios que se incorporan para garantizar un tiempo de control de calidad suficiente en función de las características.

Gran pregunta No creo que haya una respuesta correcta "oficial" a esto. Depende de qué tan rápido pueda hacer la prueba.

El problema esencial es que cada fusión, compilación o incluso implementación, potencialmente puede crear un error. Cuanto más 'ascendente' esté la cadena que pruebe, antes sabrá acerca de los errores, pero también más veces tendrá que volver a realizar la prueba.

Para estar seguro de que ha probado el software que usan los clientes, realmente tiene que probar la implementación en vivo antes de que el tráfico de los clientes (suponiendo que una aplicación web) se enrute a esos servidores a través de un patrón de implementación azul / verde.

¡Pero obviamente esto es un poco tarde en el día para ser la primera vez que revisas el código!

Si prueba una rama de liberación en un entorno qa, entonces puede correr el riesgo y reducir la prueba en vivo a pruebas de humo solamente. y aplique correcciones de errores a la rama de lanzamiento. Pero no puede evaluar si una función está completa antes de crear una versión

Si prueba el desarrollo, obtendrá mini ramas de corrección de errores. Las características aún se fusionan antes de que se evalúen, además de las características para la próxima versión pueden colisionar con la prueba de la versión actual.

Si prueba las ramas de características, necesita un millón de entornos y debe orquestar el orden de las fusiones y las aprobaciones de prueba. además de muchas nuevas pruebas.

Desde mi experiencia, recomendaría:

Prueba rápida de la rama de características en la máquina de desarrollo. solo asegúrese de que su función esté completa y los probadores / desarrolladores acuerden qué significan los requisitos.

Pruebas diarias / pruebas automatizadas en sucursales de desarrollo implementadas en servidores qa. Le permite probar todas las funciones juntas y decir cuándo está listo para lanzar.

Si todas las funciones están activadas pero la prueba no ha finalizado. Por ejemplo, el sprint está completo. haga una rama de lanzamiento e implemente en un segundo entorno qa. Esto permite que la corrección / prueba de errores en la versión 1 continúe al mismo tiempo que las características para la versión 2.

(los devotos de scrum dirán que solo debes poner correcciones de errores en el sprint 2, pero seamos prácticos)

Pruebas de humo en la implementación verde / azul en vivo antes de cambiar. Estos son súper importantes, ya que detectará errores de configuración / ambientales que nadie realmente busca durante el desarrollo.

Estoy de acuerdo con Thomas Owens. Probablemente deberías probar dos veces. Una vez en la rama de características antes de fusionarse y una vez en su rama principal antes de su lanzamiento.

De hecho, me encanta tanto ese flujo de trabajo que creé una herramienta, Topico , que crea y ejecuta automáticamente versiones desechables de su aplicación para cada solicitud de extracción, cada una con su propia URL de prueba única. Esto permite que su equipo de control de calidad pruebe ramas de características de forma aislada sin la necesidad de algún tipo de entorno de prueba dinámico configurado en su propia máquina.

Este enfoque significará que solo el código que ha pasado las pruebas en humanos llegará a su rama principal, manteniendo así su integridad.

Introduje esto en un par de compañías y ayudó mucho a nuestros ciclos de lanzamiento. Ahora podemos programar con precisión los lanzamientos, y somos mucho mejores para comprender qué es probable que llegue al próximo lanzamiento y qué tendrá que esperar para un lanzamiento futuro. Simplemente te da mucha más confianza.