¿Cómo podemos incluir solo características listas para ser lanzadas en nuestros lanzamientos de producción cada dos semanas?

Soy desarrollador de software en un equipo ágil bastante grande (tenemos ocho desarrolladores que realizan cambios activamente en un único repositorio de código). Cada dos semanas, llevamos a producción una nueva versión de nuestro software. Aquí está nuestro flujo de trabajo actual:

• Al comenzar una nueva tarea, los desarrolladores crean una "rama de características" fuera de la rama de desarrollo principal (usamos git ) y trabajan en esta nueva rama
• Una vez que un desarrollador ha terminado el trabajo en su tarea, fusionan su rama de características nuevamente en la rama de desarrollo
• El desarrollador fusiona la rama de desarrollo en la rama de QA.
• Se activa una compilación desde la rama de QA El resultado de esta compilación se implementa en nuestro entorno de control de calidad para permitir que los evaluadores comiencen sus pruebas.

Es bastante común que nuestros evaluadores encuentren problemas con estas nuevas características que se han fusionado en la rama de control de calidad. Esto significa que, en cualquier momento, el entorno de control de calidad probablemente contenga varias características nuevas, algunas probadas y libres de errores, y otras rotas. Esto dificulta la publicación porque es raro que la compilación de control de calidad esté en un estado listo para producción.

Para mitigar esto, hemos estado intentando iniciar un "congelamiento de QA", lo que significa que los desarrolladores no fusionan nuestra rama de desarrollo en la rama de QA un par de días antes del lanzamiento. Las correcciones de errores en el entorno de control de calidad se realizan directamente en la rama de control de calidad y se fusionan con la rama de desarrollo. Teóricamente, esto mantiene las características nuevas y rotas fuera del control de calidad y al mismo tiempo nos permite solucionar problemas que ya están en el control de calidad.

Si bien este concepto de "congelación de QA" ha sido parcialmente exitoso, es difícil de coordinar y las personas a menudo se confunden acerca de si se les permite fusionarse con QA. También ha sido difícil establecer una fecha límite de "congelación de control de calidad": a todos les gusta la idea de un respiro entre la congelación y el lanzamiento, pero en la práctica, prefieren tener su función en el próximo lanzamiento que respetar la fecha límite.

¿Hay una mejor manera de garantizar que tengamos una compilación limpia para nuestros lanzamientos cada dos semanas?

Hay algunos problemas flotando en esto que están causando problemas que está experimentando.

El primero es la rama QA de larga ejecución. Tener una rama de larga ejecución que es paralela a la línea principal de desarrollo puede ser una fuente de confusión porque hay diferentes esfuerzos que deben replicarse tanto en la rama de control de calidad como en la línea principal. Esto significa que está revisando las correcciones de la rama de control de calidad que deben fusionarse con la línea principal (no es malo), o está registrando la línea principal que se fusionó con la rama de control de calidad (una fuente de posibles errores) .

El otro problema con la rama paralela de larga ejecución es que es posible que los archivos se desincronicen permanentemente. Una corrección de código que nunca se fusiona, o una configuración necesaria para compilaciones de producción que nunca se prueba y que forma parte de la línea principal de desarrollo.

A continuación, tiene roles en los que se incurre. Esto significa que la función de empaquetado (más sobre esto más adelante) no se está aislando lo suficiente.

En el modelo git-flow , la rama de lanzamiento se ramifica desde el desarrollo ( no el desarrollo se fusionó con el control de calidad) y todas las correcciones se registran en la rama de lanzamiento y luego se fusionan de nuevo con la rama de desarrollo.

Parte de la filosofía de la ramificación se puede encontrar en Estrategias avanzadas de ramificación de SCM (considero que es una lectura excelente). Esto se centra en los roles que puede asumir cada rama. La rama de lanzamiento asume el rol de empaque.

La función de empaquetado a menudo se confunde con la acumulación o, más comúnmente, con las funciones principales. Una vez que se ha realizado el desarrollo y mantenimiento previstos y se ha realizado cualquier acumulación, es hora de preparar el código para su lanzamiento. Tal esfuerzo puede no ser trivial, ya que requiere un equipo de ingenieros de lanzamiento y soluciones adicionales más allá de las ya realizadas. La política en una rama de empaque es significativamente diferente de la de una rama de mantenimiento, como sugiere la función de empaque, solo se deben abordar los cambios necesarios para hacer que el producto sea liberable.

• Se bifurca desde el punto de desarrollo hasta la rama de lanzamiento. La rama de lanzamiento que QA construye obtiene una rama y no se fusiona con el desarrollo.
  • Si desea seguir ese camino, con nombres y ganchos consistentes, es posible evitar que se realice una fusión en una rama de liberación.
• Arregle todo lo que necesita ser arreglado en la rama de lanzamiento y combine esos cambios con la línea principal.
• Al final del esfuerzo de lanzamiento, combine la rama de lanzamiento en la rama "lanzamientos vaya aquí" y etiquétela como tal.
  • Algunos sitios no tienen una rama "lanzamientos vaya aquí" y simplemente dejan el final de la rama de lanzamiento colgando con una etiqueta.

Uno debería considerar seriamente aplicar la totalidad de git-flow en su lugar. Esto no está muy lejos de lo que se está haciendo actualmente y pone un poco de disciplina y consistencia en lo que significa cada rama y cómo cada rama interactúa con las demás.

Me parece que el problema es que tiene una sola rama de control de calidad.

Para cada versión, cree una rama de control de calidad separada de la troncal / master de desarrollo primario. Luego, combine solo las correcciones de errores para las características de esa rama, nunca nuevas características. Haga que QA pruebe esa rama.

De esta manera, el "congelamiento" es bastante evidente: está en el nombre de la sucursal. Se podría utilizar algo como, no sé, release/26/10/2015. Entonces es obvio que nadie debería fusionarse en nuevas características después de esto.

Es especialmente útil si ni siquiera bifurcas la rama hasta que se congele. Las personas pueden fusionarse para dominar en cualquier momento, simplemente no será parte de esta versión si no se hace a tiempo para que se pruebe.

No tenga una sola rama de control de calidad de larga duración, solo está pidiendo problemas. Bifurcación de la rama de desarrollo principal para cada versión y control de calidad de esa rama.

De alguna manera, está asignado al modelo de ramificación Desarrollo-PRINCIPAL-Producción que se ve a continuación. Se dice que el área sobre MAIN es el área de desarrollo. El área debajo de PRINCIPAL es el área de producción.

Aspectos destacados de este modelo que considero relevantes para usted:

• Sus desarrolladores necesitan Forward Integrate (FI) (FI = fusionarse lejos de MAIN) con frecuencia (2-3 veces por semana) en sus sucursales de DEV para garantizar que sus últimos cambios siempre tengan en cuenta los últimos desarrollos generales.
• Sus desarrolladores necesitan Reverse Integrate (RI) (RI = fusionarse hacia MAIN) en la rama TEST solo cuando hayan alcanzado un hito de finalización de características que quieran exponer a QA y para el que estén listos para proporcionar soluciones rápidas en respuesta a los comentarios de QA. Las correcciones se realizarán en la rama TEST e inmediatamente FI en su rama DEV.
• Nunca RI de ninguna rama de DEV a MAIN
• Siempre RI de la rama TEST a PRINCIPAL, exclusivamente cuando su QA considera que la calidad de TEST está bien. Mantenga un umbral de alta calidad para fusionarse con MAIN. Como mínimo, su gerente de producto debe poder siempre mostrar una versión funcional de su producto desde la última confirmación en MAIN.
• Cree sucursales en el área de producción solo según sea necesario. Su servidor de compilación siempre debe etiquetar todas las sucursales, incluidas las del área de desarrollo, y la fuente de cualquier compilación / lanzamiento debe ser identificable en todo momento, independientemente de la sucursal de la que proviene.
• Tome lanzamientos para producción solo de MAIN o del área de producción. Si más adelante necesita proporcionar una solución para una versión lanzada exacta (es decir, no puede simplemente dar la última versión de MAIN), cree una rama en el área de producción a partir de la etiqueta PRINCIPAL de la versión defectuosa, cuando la solución sea necesaria. Siempre solucione el problema en la rama HotFix e inmediatamente RI en MAIN y FI en TEST.

Sospecho que tienes problemas porque:

• Sus desarrolladores RI en el código TEST que no está completo
• Sus desarrolladores RI en TEST sin obtener luz verde de QA (es decir, QA no tiene el control de lo que se inyecta en TEST)
• Cuando QA informa un error en TEST, sus desarrolladores lo arreglan en su rama DEV y luego RI en TEST. Esta es una mala práctica importante porque la fusión siempre traerá otra basura de desarrollo incompleta. Siempre deben arreglarlo en TEST y luego FI en su rama DEV. Si no es reparable en TEST, entregaron basura total en primer lugar y usted tiene mayores problemas.
• Sus desarrolladores no realizan FI con suficiente frecuencia de TEST, por lo que desestabilizan TEST cada vez que entregan allí. Es un buen arte equilibrar la frecuencia de FI en DEV. Posponga demasiado y será extremadamente costoso y arriesgado justo antes de la entrega, lo que nunca desea. Hágalo con demasiada frecuencia y no obtendrá ningún trabajo de desarrollo real si se superpone demasiado con el trabajo entregado por otras personas en TEST mientras tanto.

Según tengo entendido la pregunta tienes dos problemas. (a) las características rotas se fusionan con las buenas características que desea lanzar; (b) desea poder liberar las buenas características mientras retiene las rotas. Como restricción de las posibles soluciones, supongo que desea que su prueba de control de calidad final / oficial se realice en una rama integrada que contenga todas las características programadas para la próxima versión.

Independientemente de su modelo de ramificación SCM, le sugiero que pruebe uno o ambos de los siguientes:

1. Asigne un recurso de control de calidad a cada equipo de características. Pídales que realicen algunas pruebas de características en las compilaciones desde la rama de características, y deles autoridad para decidir cuándo una característica es lo suficientemente buena como para fusionarse. Idealmente, pídales que trabajen en colaboración con (el resto) del equipo, para que las cosas se prueben poco después de ser escritas. (Tenga en cuenta que esto no significa que tengan que hacer todas las pruebas ellos mismos).
2. Utilice las funciones de alternancia, ya sea en lugar de ramas de funciones o además de ellas. Bien hecho, los conmutadores de funciones le permiten desactivar una función rota sin intentar quitarla del código, para que pueda probar y liberar las otras funciones. Los clientes no pueden acceder al tipo de alternar del que estoy hablando; no desea probar un número de combinaciones que aumenta exponencialmente. Establece los conmutadores en la rama de control de calidad para que coincidan con las características que planea lanzar, y si el plan cambia porque una característica no está lista, cambia esa alternancia.

Una solución muy simple que he visto trabajar en un equipo un poco más grande que el suyo es hacer que todos trabajen e implementen desde una sola sucursal.

Dices que el equipo es ágil pero no está claro si estás trabajando en sprints (es decir, Scrum) o un enfoque de flujo más continuo (es decir, Kanban). Asumiendo que estás haciendo sprints, el objetivo del equipo es que el código sea liberable al final de cada sprint, para tu lanzamiento quincenal. No hay confusión en cuanto a si una característica romperá a otra, ya que todas se han desarrollado juntas. Los probadores pueden obtener acceso a funciones en fragmentos más pequeños, ya que la sobrecarga de los desarrolladores para entregarles es menor. Y realmente no necesita un QA-Freeze, en su lugar, todos saben cuándo es el final del sprint y no deben asumir el trabajo que no pueden terminar o dejar en un estado desplegable (es decir, deshabilitado).

Obviamente, hay ventajas y desventajas de cualquier enfoque, lo presento como una opción, no necesariamente la "mejor manera".

La razón por la que tiene estos problemas es porque su código lanzado a QA no es de una calidad lo suficientemente buena (¡¿y hay alguien ?!), por lo que debe comenzar a obtener una mejor versión de QA para que no necesiten recibir bigfixes tan a menudo. la forma más sencilla de hacer esto es introducir una rama intermediaria a la que liberes (vamos a llamarlo prueba). Esto todavía está bajo el mandato de desarrollo, pero permite a los desarrolladores presionar para que continúen trabajando, al mismo tiempo que tiene una sucursal integrada que debería ser lo suficientemente buena como para enviarla a QA.

Se pueden realizar pruebas de integración en esta rama para encontrar los errores que el QA está encontrando actualmente, los errores se pueden corregir en la rama original y luego fusionarse nuevamente, y nuevamente hasta que se corrijan los errores en esta rama directamente (recomiendo el ex). Una vez que ha pasado una carga de pruebas básicas, puede enviarse a QA para los "dedos pegajosos del usuario y el ¿qué hicieron?" pruebas.

Por lo tanto, este enfoque está diseñado para proteger la rama de control de calidad de las características de desarrollo rotas, ya sea porque la característica no se codificó lo suficientemente bien o si hubo problemas de integración inesperados, no importa. Solo las ramas de desarrollo que pasan las pruebas de integración pueden ser promovidas a control de calidad.