¡Nuestro equipo de desarrollo ha estado utilizando la estrategia de ramificación de GitFlow y ha sido excelente!
Recientemente reclutamos un par de probadores para mejorar la calidad de nuestro software. La idea es que un probador pruebe o controle cada característica.
En el pasado, los desarrolladores trabajan en características en ramas de características separadas y las fusionan de nuevo con la developrama cuando terminan. El desarrollador probará su trabajo él mismo en esa featurerama. Ahora con los probadores, comenzamos a hacer esta pregunta
¿En qué rama debe probar el probador las nuevas funciones?
Obviamente, hay dos opciones:
- en la rama de características individuales
- en la
developrama
Prueba en la rama de desarrollo
Inicialmente, creíamos que este es el camino seguro porque:
- La función se prueba con todas las demás funciones fusionadas con la
developrama desde que comenzó su desarrollo. - Cualquier conflicto puede ser detectado más temprano que tarde
- Facilita el trabajo del probador, solo está tratando con una rama (
develop) en todo momento. No necesita preguntarle al desarrollador 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
developrama está contaminada con insectos.Cuando el probador encuentra errores o conflictos, los informa al desarrollador, que soluciona el problema en la rama de desarrollo (la rama de características se abandonó una vez fusionada), y podría haber más correcciones necesarias después. Múltiples confirmaciones o fusiones de subsecuencia (si una rama se
developvuelve a crear fuera de la rama para corregir los errores), hace posible deshacer la función desde ladeveloprama muy difícil si es posible. Hay múltiples características que se fusionan y se fijan en ladevelopsucursal en diferentes momentos. Esto crea un gran problema cuando queremos crear una versión con solo algunas de las características de ladeveloprama
Prueba en la rama de funciones
Así que pensamos nuevamente y decidimos que deberíamos probar características en las ramas de características. Antes de probar, fusionamos los cambios de la developrama a la rama característica (ponerse al día con la developrama). Esto es bueno:
- Todavía prueba la característica con otras características en la corriente principal
- El desarrollo adicional (por ejemplo, corrección de errores, resolución de conflictos) no contaminará la
developrama; - Puede decidir fácilmente no lanzar la función 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 pedirle ayuda al desarrollador. Nuestros probadores se especializan en pruebas y no son capaces de codificar.
- una característica podría probarse sin la existencia de otra nueva característica. 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
developrama. Esto significa que tendrá que probar contra ladeveloprama nuevamente cuando ambas características se fusionen con la rama desarrollada de todos modos. Y debes recordar probar esto en el futuro. - Si las características A y B se prueban y aprueban, pero cuando se fusiona se identifica un conflicto, los dos desarrolladores de ambas características creen que no es su culpa / trabajo porque su característica se ramificó después de la prueba. Hay un gasto 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 lidiar con esto. Me encantaría saber cómo otros equipos manejan este tipo de situaciones.
