git testing qa git-flow

Estrategia de ramificación de Git integrada con proceso de prueba/QA



testing git-flow (5)

Nuestro equipo de desarrollo ha estado utilizando la estrategia de ramificación de GitFlow y ¡ha sido genial!

Recientemente, reclutamos un par de probadores para mejorar la calidad de nuestro software. La idea es que cada característica debe ser probada / QA por un probador.

En el pasado, los desarrolladores trabajan en funciones en ramas de características separadas y las fusionan de nuevo a la rama de develop cuando termina. El desarrollador probará su trabajo él mismo en esa rama de feature . Ahora con los probadores, comenzamos a hacer esta pregunta

¿En qué rama debería el probador probar nuevas características?

Obviamente, hay dos opciones:

  • en la rama de características individuales
  • en la rama de develop

Pruebas en la rama de desarrollo

Inicialmente, creímos que este era el camino seguro porque:

  • La característica se prueba con todas las demás características fusionadas con la rama de develop desde que comenzó su desarrollo.
  • Cualquier conflicto puede ser detectado antes que tarde
  • Facilita el trabajo del examinador, solo se ocupa de una rama ( develop ) en todo momento. No es necesario que pregunte al desarrollador qué rama es para qué característica (las ramas de características son sucursales personales administradas exclusiva y libremente por los desarrolladores relevantes)

El mayor problema con esto es:

  • La rama de develop está contaminada con errores.

    Cuando el probador encuentra errores o conflictos, los informa al desarrollador, quien soluciona el problema en la rama de desarrollo (la rama de características se abandonó una vez fusionada) y es posible que luego se requieran más arreglos. La subsecuencia múltiple se compromete o se fusiona (si una rama se recrea fuera de develop rama nuevamente para corregir los errores) hace que retirar la característica de la rama de develop muy difícil si es posible. Hay varias funciones que se fusionan y se fijan en la rama de develop en diferentes momentos. Esto crea un gran problema cuando queremos crear una versión con solo algunas de las características en la rama de develop

Pruebas en la rama de características

Así que pensamos nuevamente y decidimos que deberíamos probar las características en las ramas de características. Antes de realizar la prueba, fusionamos los cambios de la rama de develop a la rama de característica (alcanzamos la rama de develop ). Esto es bueno:

  • Todavía prueba la función con otras características en la corriente principal
  • Un mayor desarrollo (por ejemplo, corrección de errores, resolución de conflictos) no contaminará la rama de develop ;
  • Puede decidir fácilmente no lanzar la característica hasta que esté completamente probada y aprobada;

Sin embargo, hay algunos inconvenientes

  • El probador debe fusionar el código, y si hay algún conflicto (muy probable), tiene que pedir ayuda al desarrollador. Nuestros probadores se especializan en pruebas y no son capaces de codificar.
  • una característica podría ser probada sin la existencia de otra característica nueva. por ejemplo, las características A y B están bajo prueba al mismo tiempo, las dos características no se conocen entre sí porque ninguna de ellas se ha fusionado con la rama de develop . Esto significa que tendrá que probar nuevamente contra la rama de develop cuando ambas funciones se fusionen con la rama de desarrollo. Y debes recordar probar esto en el futuro.
  • Si las características A y B son probadas y aprobadas, pero cuando se fusiona se identifica un conflicto, ambos desarrolladores de ambas características creen que no es su propia culpa / trabajo porque su característica se ha pasado la prueba. Hay una sobrecarga adicional en la comunicación y, a veces, quien resuelve el conflicto se frustra.

Arriba está nuestra historia. Con recursos limitados, me gustaría evitar probar todo en todas partes. Todavía estamos buscando una mejor manera de lidiar con esto. Me encantaría escuchar cómo otros equipos manejan este tipo de situaciones.

Antes de la prueba, fusionamos los cambios de la rama de desarrollo a la rama de características

No. No, especialmente si ''nosotros'' es el verificador de QA. La fusión implicaría resolver conflictos potenciales, lo cual es mejor hecho por los desarrolladores (conocen su código), y no por el verificador de QA (que debe proceder a realizar la prueba lo más rápido posible).

Haga que el desarrollador haga una rebase de su rama de feature sobre el devel , y presione esa rama de feature (que el desarrollador ha validado al compilar y trabajar en la parte superior del estado de rama de devel más reciente).
Eso permite:

Cada vez que el probador detecte un error, lo informará al desarrollador y eliminará la rama de características actual.
El desarrollador puede:

  • arreglar el error
  • rebase en la parte superior de una rama desarrollada recientemente (nuevamente, para asegurarse de que su código funcione en integración con otras características validadas)
  • empujar la rama de feature .

Idea general: asegúrese de que el desarrollador realice la parte de fusión / integración, dejando las pruebas al control de calidad.

El mejor enfoque es la integración continua , donde la idea general es fusionar las ramas de características en la rama de desarrollador con la mayor frecuencia posible. Esto reduce la sobrecarga de los dolores de fusión.

Confíe en las pruebas automatizadas tanto como sea posible, y las compilaciones se inician automáticamente con las pruebas de unidad de Jenkins. Haga que los desarrolladores hagan todo el trabajo con la fusión de sus cambios en la rama principal y proporcionen pruebas unitarias para todo su código.

Los evaluadores / QA pueden participar en revisiones de códigos, marcar pruebas de unidades y escribir pruebas de integración automáticas para agregarlas al conjunto de regresiones a medida que se completan las funciones.

Para obtener más información, consulte este link .

La forma en que lo hacemos es la siguiente:

Probamos en las ramas de características después de fusionar el último código de rama de desarrollo en ellas. La razón principal es que no queremos "contaminar" el código de bifurcación de desarrollo antes de que se acepte una característica. En caso de que una característica no sea aceptada después de la prueba, pero nos gustaría lanzar otras características ya fusionadas en el desarrollo que sería un infierno. Develop es una rama de la cual se realiza una liberación y, por lo tanto, debería estar en un estado liberable. La versión larga es que probamos en muchas fases. Más analíticamente:

  1. El desarrollador crea una rama de características para cada nueva característica.
  2. La rama de características se implementa (automáticamente) en nuestro entorno de PRUEBA con cada compromiso que el desarrollador debe probar.
  3. Cuando el desarrollador finaliza la implementación y la característica está lista para ser probada, fusiona la rama de desarrollo en la rama de características y despliega la rama de características que contiene todos los cambios de desarrollo más recientes en TEST.
  4. El probador prueba en TEST. Cuando termina, "acepta" la historia y fusiona la rama característica en el desarrollo. Dado que el desarrollador había fusionado previamente la rama de desarrollo en función, normalmente no esperamos demasiados conflictos. Sin embargo, si ese es el caso, el desarrollador puede ayudar. Este es un paso complicado, creo que la mejor manera de evitarlo es mantener las características lo más pequeñas / específicas que sea posible. Diferentes características tienen que fusionarse eventualmente, de una forma u otra. Por supuesto, el tamaño del equipo juega un papel en la complejidad de este paso.
  5. La rama de desarrollo también se despliega (automáticamente) en TEST. Tenemos una política que, a pesar de que las compilaciones de ramas de características pueden fallar, la rama de desarrollo nunca debe fallar.
  6. Una vez que hemos alcanzado un congelamiento de características, creamos un lanzamiento del desarrollo. Esto se implementa automáticamente en STAGING. Se llevan a cabo extensas pruebas de extremo a extremo antes de la implementación de producción. (ok tal vez exagero un poco, no son muy extensas, pero creo que deberían serlo). Idealmente, los beta testers / colegas, es decir, los usuarios reales deberían probar allí.

Que piensas de esta aproximación?

No confiaría solo en las pruebas manuales. Automatizaría las pruebas de cada rama de características con Jenkins. Configuré un laboratorio VMWare para ejecutar pruebas de Jenkins en Linux y Windows para todos los navegadores. Es realmente una increíble solución de prueba cruzada de navegador cruzado. Pruebo funcional / integración con Selenium Webdriver. Mis pruebas de selenio se ejecutan bajo Rspec. Y los escribí especialmente para ser cargados por jRuby en Windows. Ejecuto pruebas unitarias tradicionales bajo pruebas de Rspec y Javascript bajo Jasmine. Configuré pruebas sin cabeza con Phantom JS.

Usamos lo que llamamos "oro", "plata" y "bronce". Esto podría llamarse prod, staging y qa.

He llegado a llamar a esto el modelo de crisol. Funciona bien para nosotros porque tenemos una gran necesidad de control de calidad en el aspecto comercial ya que los requisitos pueden ser difíciles de entender frente a los aspectos técnicos.

Cuando un error o característica está listo para la prueba entra en "bronce". Esto desencadena una construcción de jenkins que empuja el código a un entorno preconstruido. Nuestros probadores (no súper expertos en tecnología) simplemente presionan un enlace y no se preocupan por el control de la fuente. Esta compilación también ejecuta pruebas, etc. Hemos avanzado una y otra vez en esta compilación empujando el código al entorno de prueba / qa si las pruebas (unidad, integración, selenio) fallan. Si prueba en un sistema separado (lo llamamos lead), puede evitar que los cambios sean enviados a su entorno qa.

El miedo inicial fue que tendríamos muchos conflictos entre estas características. Sucede que la característica X hace que parezca que la característica Y se está rompiendo, pero es lo suficientemente infrecuente y realmente ayuda. Ayuda a obtener una gran cantidad de pruebas fuera de lo que parece es el contexto del cambio. Muchas veces, con suerte, descubrirás cómo tus efectos de cambio son paralelos al desarrollo.

Una vez que una característica pasa QA, la movemos a "plata" o puesta en escena. Se ejecuta una compilación y se vuelven a ejecutar las pruebas. Semanalmente promovemos estos cambios en nuestro árbol de "oro" o prod y luego los implementamos en nuestro sistema de producción.

Los desarrolladores comienzan sus cambios desde el árbol de oro. Técnicamente, podrías comenzar desde la puesta en escena, ya que subirán pronto.

Las soluciones de emergencia se vierten directamente en el árbol de oro. Si un cambio es simple y difícil de QA, puede ir directamente a la plata, que llegará al árbol de pruebas.

Después de nuestro lanzamiento, aplicamos los cambios en oro (prod) a bronce (prueba) solo para mantener todo sincronizado.

Es posible que desee rebase antes de ingresar a su carpeta de etapas. Hemos encontrado que purgar el árbol de prueba de vez en cuando lo mantiene limpio. Hay momentos en que las funciones se abandonan en el árbol de pruebas, especialmente si un desarrollador se va.

Para las funciones grandes de varios desarrolladores, creamos un repositorio compartido por separado, pero lo fusionamos en el árbol de pruebas de la misma manera cuando estamos listos. Las cosas tienden a rebotar en el control de calidad, por lo que es importante mantener sus conjuntos de cambios aislados para que pueda agregar y luego fusionar / aplastar en su árbol de etapas.

"Hornear" también es un buen efecto secundario. Si tiene algún cambio fundamental que quiere dejar sentado durante un tiempo, hay un buen lugar para ello.

También tenga en cuenta que no mantenemos versiones anteriores. La versión actual es siempre la única versión. Aun así, es probable que tengas un árbol de cocción maestro donde tus probadores o comunidad puedan ver cómo interactúan los diversos colaboradores.