Estrategia de ramificación de Git integrada con el proceso de pruebas / control de calidad

Nuestro equipo de desarrollo ha estado utilizando la estrategia de ramificación 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 trabajaban en características en ramas de características separadas y las fusionaban de nuevo a la rama develop cuando terminaban. El desarrollador probará su trabajo él mismo en esa rama feature. Ahora con los probadores, empezamos a preguntar esto Pregunta

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

Obviamente, hay dos opciones:

  • en la rama de entidad individual
  • en la rama develop

Pruebas En La Rama Develop

Inicialmente, creímos que este es el camino seguro porque: {[18]]}

  • La característica se prueba con todas las demás características fusionadas a la rama develop desde que se inició el desarrollo.
  • Cualquier conflicto puede detectarse antes que después
  • Facilita el trabajo del probador, solo está tratando con una rama (develop) en todo momento. No necesita preguntar al desarrollador sobre qué rama es para qué característica (las ramas de características son ramas personales administradas exclusiva y libremente por desarrolladores relevantes )

El mayor problema con esto es:

  • La rama develop está contaminada con errores.

    Cuando el probador encuentra errores o conflictos, informa de vuelta al desarrollador, que soluciona el problema en la rama develop (la rama feature se abandonó una vez fusionada ), y podría haber más correcciones necesarias después. Commits o merges múltiples subsecuencias (si una rama es recreada de nuevo fuera de develop para corregir los errores) hace que revertir la característica de la rama develop sea muy difícil si es posible. Hay varias características que se fusionan y se arreglan en la rama develop en diferentes momentos. Esto crea un gran problema cuando queremos cree una versión con solo algunas de las características de la rama develop

Pruebas En La Rama De Características

Así que pensamos de nuevo y decidimos que deberíamos probar las entidades en las ramas de entidades. Antes de probar, combinamos los cambios de la rama develop a la rama feature ( pongamos al día con la rama develop). Esto es bueno:

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

Sin embargo, hay algunos inconvenientes

  • El probador tiene que hacer la fusión del 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 nueva característica. por ejemplo, Característica 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 develop. Esto significa que tendrá que probar con la rama develop de nuevo cuando ambas características se fusionen con la rama develop de todos modos. Y tienes que recordar probar esto en el futuro.
  • Si las características A y B se prueban y aprueban, pero cuando se fusionan se identifica un conflicto, ambos desarrolladores de ambas características creen que no es suyo culpa propia / trabajo porque su rama característica más allá de la prueba. Hay una sobrecarga adicional en la comunicación, y a veces quien resuelve el conflicto se siente frustrado.

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

Author: nycynik, 2013-08-22
Source

5 answers

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 la rama 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 develop, eso sería un infierno. Develop es una rama desde la que se realiza una liberación y, por lo tanto, es mejor que esté en un estado liberable. El largo versión es que probamos en muchas fases. Más analíticamente:

  1. El desarrollador crea una rama de característica para cada nueva característica.
  2. La rama de características se implementa (automáticamente) en nuestro entorno de PRUEBA con cada confirmación para que el desarrollador la pruebe.
  3. Cuando el desarrollador ha terminado con la implementación y la característica está lista para ser probada, fusiona la rama develop en la rama feature y despliega la rama feature que contiene todos los últimos cambios en develop PRUEBA.
  4. El probador prueba en PRUEBA. Cuando termina, "acepta" la historia y fusiona la rama de características en develop. Dado que el desarrollador había fusionado previamente la rama develop en feature, normalmente no esperamos demasiados conflictos. Sin embargo, si ese es el caso, el desarrollador puede ayudar. Este es un paso difícil, creo que la mejor manera de evitarlo es mantener las características tan pequeñas/específicas como sea posible. Diferentes características tienen que ser finalmente fusionadas, de una manera u otra. Por supuesto, el tamaño del equipo juega un papel en la complejidad de este paso.
  5. La rama develop también se despliega (automáticamente) en TEST. Tenemos una política que a pesar de que las compilaciones de la rama features pueden fallar, la rama develop nunca debería fallar.
  6. Una vez que hemos alcanzado una congelación de características, creamos una versión desde develop. Esto se implementa automáticamente en el ensayo. Extensas pruebas de extremo a extremo se llevan a cabo allí antes del despliegue de producción. (ok tal vez exagere un poco no son muy extensos pero creo deberían serlo). Idealmente los probadores beta / colegas, es decir, los usuarios reales deben probar allí.

¿Qué opinas de este enfoque?

 69
Author: Aspasia,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-07-20 16:11:56

Antes de probar, fusionamos los cambios de la rama develop a la rama feature

No. No, especialmente si 'nosotros' es el probador de QA. La fusión implicaría resolver conflictos potenciales, lo cual es mejor que lo hagan los desarrolladores (que conocen su código), y no QA tester (que debería proceder a probar lo más rápido posible).

Hacer que el desarrollador haga un rebase de su rama feature encima de devel, y empuje que feature rama (que ha sido validado por el desarrollador como compilador y trabajando sobre el estado de rama devel más reciente).
Eso permite:

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

  • corrige el error
  • rebase encima de una rama develop recientemente recuperada (de nuevo, para estar seguro de que su código funciona en integración con otras características validadas)
  • empuja la rama feature.

Idea general: asegúrese de que la parte merge / integration sea hecho por el desarrollador, dejando las pruebas al QA.

 28
Author: VonC,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-07-27 11:11:49

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 dolores de fusión.

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

Los evaluadores / QA pueden participe en revisiones de código, marque las pruebas unitarias y escriba pruebas de integración automatizadas para agregarlas a la suite de regresión a medida que se completen las funciones.

Para más información echa un vistazo a este enlace.

 8
Author: Johnny Z,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-09-18 13:38:29

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 QA en el lado comercial de las cosas, ya que los requisitos pueden ser difíciles de entender frente a los técnicos.

Cuando un bug o característica está lista para probar, entra en "bronce". Esto desencadena una compilación de Jenkins que envía el código a un entorno preconstruido. Nuestros probadores (no super techies por cierto) simplemente pulsa un enlace y no te importa el control de código fuente. Esta compilación también ejecuta pruebas, etc. Hemos ido y venido en esta compilación empujando el código al entorno testing \ qa si las pruebas (unit, integration, selenium ) fallan. Si realiza pruebas en un sistema separado ( lo llamamos lead), puede evitar que los cambios se envíen a su entorno de control de calidad.

El temor inicial era que tendríamos muchos conflictos entre estas características. Sucede si la característica X lo hace parece que la característica Y se está rompiendo, pero es lo suficientemente infrecuente y en realidad ayuda. Ayuda a obtener una amplia franja de pruebas fuera de lo que parece ser el contexto del cambio. Muchas veces por suerte descubrirá cómo su cambio afecta el desarrollo paralelo.

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

Los desarrolladores comienzan sus cambios del árbol de oro. Técnicamente se podría empezar desde la puesta en escena ya que los subirán pronto.

Las correcciones de emergencia se introducen directamente en el árbol de oro. Si un cambio es simple y difícil para QA, puede ir directamente a silver, que encontrará su camino al árbol de pruebas.

Después de nuestro lanzamiento, empujamos los cambios en gold(prod) a bronze(testing) solo para mantener todo sincronizado.

Es posible que desee rebase antes de empujar en su carpeta de ensayo. Hemos encontrado que purgar el árbol de pruebas de vez en cuando lo mantiene limpio. Hay momentos en que las características se abandonan en el árbol de pruebas, especialmente si un desarrollador se va.

Para grandes características de varios desarrolladores, creamos un repositorio compartido separado, pero lo fusionamos en el árbol de pruebas de la misma manera cuando estemos listos. Las cosas tienden a rebotar de QA, por lo que es importante mantener sus conjuntos de cambios aislados para que pueda agregar y luego fusionar/aplastar en su árbol de puesta en escena.

"Hornear" también es un buen lado efecto. Si usted tiene algún cambio fundamental que desea dejar sentarse por un tiempo hay un buen lugar para ello.

También ten en cuenta que no mantenemos versiones anteriores. La versión actual es siempre la única versión. Aún así, probablemente podrías tener un árbol maestro para hornear donde tus probadores o comunidad puedan ver cómo interactúan las cosas de varios contribuyentes.

 3
Author: Eric Twilegar,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-07-30 22:50:31

No confiaría solo en las pruebas manuales. Yo automatizaría las pruebas de cada rama de características con Jenkins. Configuré un laboratorio de VMware para ejecutar pruebas Jenkins en Linux y Windows para todos los navegadores. Es realmente una impresionante solución de pruebas multiplataforma y 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. Corro pruebas unitarias tradicionales bajo Rspec y pruebas Javascript bajo Jasmine. Me configuración de pruebas sin cabeza con Phantom JS.

 1
Author: nathanengineer,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-09-08 04:16:13