Estrategia de lanzamiento para múltiples sucursales de entidades Git que se prueban simultáneamente

7

Tenemos tres entornos: Dev , UAT y Prod . Usamos TFS para programar los lanzamientos de nuestra rama master en Dev para nuestra verificación interna, luego UAT para la verificación comercial y, por supuesto, finalmente a Prod una vez que se apruebe.

Recientemente hemos adoptado una nueva estrategia de ramificación de Git ligera de la siguiente manera:

master está siempre listo para prod. En cualquier punto, master debería poder implementarse en producción.

Todo el desarrollo nuevo se realiza en una rama de características (tema) separada de la siguiente manera:

  1. Crea una nueva rama de características fuera de master , llámala FeatureA
  2. Desarrolle FeatureA hasta que se complete
  3. Una vez que finalice FeatureA , libérelo a Dev y luego UAT
  4. Una vez que la empresa se apaga en FeatureA en UAT , se considera listo para la producción. Combine FeatureA en master , luego implemente la nueva rama master en Dev y luego UAT . Durante el proceso, "haga una prueba de humo" en la rama en UAT para asegurarse de que la fusión resultante en el maestro no causó efectos secundarios imprevistos. Una vez probado en humo, suelte a Prod .

El problema que estamos encontrando ahora mismo es que podemos tener múltiples funciones desarrolladas en paralelo, todas las cuales posiblemente deban implementarse en el entorno de prueba para la verificación al mismo tiempo. El enfoque que hemos tomado para resolver este problema es:

Si FeatureA y FeatureB necesitan estar en UAT al mismo tiempo, entonces:

  1. Cree una nueva rama, FeatureAandB , que abarcará ambas características
  2. Combinar FeatureA en FeatureAandB
  3. Combinar FeatureB en FeatureAandB
  4. Suelte FeatureAandB a Dev , luego UAT

La desventaja de esto es que es poco probable que tanto FeatureA como FeatureB se verifiquen UAT al mismo tiempo. Si se verifica FeatureA y FeatureB no, debemos liberar FeatureA para producir sin FeatureB . Lo que hemos discutido en este escenario es:

  1. Combinar FeatureA (no la rama conjunta, sino simplemente FeatureA) en master
  2. Suelte master a Dev , luego UAT para una prueba de humo rápida, y finalmente Prod
  3. Una vez en prod, relanzar solo FeatureB a Dev luego UAT para que la prueba pueda continuar.

La desventaja de esto es que afecta directamente a cualquier prueba para FeatureB , y potencialmente desenrolla cualquier trabajo que los probadores hayan realizado con FeatureB .

¿Cómo gestionas las múltiples funciones que viven al mismo tiempo en cada entorno y que son liberadas potencialmente independientes entre sí? Podemos mitigar el problema un poco más si tenemos múltiples entornos o pruebas UAT por turnos mucho más rápido, pero al final del día puede existir el mismo problema.

Tampoco me opongo a escuchar estrategias de ramificación alternativas.

    
pregunta Sam 12.02.2018 - 20:07

2 respuestas

5

Ahh. ¡Felicidades! ¡Has destruido un cuello de botella y has descubierto el siguiente! Ahora es el momento de mirar en realidad integrando continuamente su código. Como se ha enterado, es difícil entregar continuamente cuando su código bajo dev no se integra continuamente, pero ¿cómo hace que esto funcione?

No hay más ramas de características.

No. Seriamente. No más ramas características.

Es hora de introducir característica alterna en su sistema. En lugar de ofrecer nuevas funciones mediante la entrega de código, debe tener un control completo sobre cuándo se activa una función para un entorno determinado. En otras palabras, desea tener una configuración específica del entorno que active y desactive las características. Esto desacopla los lanzamientos de código de lanzamientos de características.

    
respondido por el RubberDuck 13.02.2018 - 04:06
5

Pruebe las funciones por separado y en orden, esa es realmente la mejor manera de hacerlo. Por lo general, lo que se hace primero se prueba primero, pero las necesidades comerciales pueden cambiar esa prioridad. Cuando se acepta FeatureA , se fusiona en la rama principal ( dev , UAT o master en su caso, según corresponda), esa rama se fusiona en FeatureB y luego se prueba la característica B. A se prueba primero, luego B, luego C, etc., y cada rama de características se actualiza a medida que se prueban y aceptan otras características.

Al probar las funciones por separado, mantienes el foco en una función y un equipo es responsable de solucionar cualquier problema. Hay una clara responsabilidad de mantener el código en buen estado cuando se manejan los conflictos de combinación (en este caso, el equipo featureB necesita fusionar dev y lidiar con cualquier conflicto de fusión, asegurando que se mantenga el código de featureA ). Las funciones separadas también facilitan la asignación de "culpa" cuando se descubre un problema, no el tipo de culpa "por qué rompiste esto", pero "esta función está causando un problema, elimínalo de dev hasta que podamos clasificar fuera "tipo de culpa

Si encuentra que se gastan una gran cantidad de FeatureX de sucursales en espera de las pruebas o se completan varias sucursales al mismo tiempo, puede dividirlas en funciones más pequeñas o asignar más recursos para las pruebas. Ambos enfoques deberían disminuir el tiempo para probar una rama individual.

Las características similares que se completarán al mismo tiempo se pueden desarrollar mejor en una sola rama. Eso es algo de lo que propones con la rama FeatureAandB , pero en este caso, se aceptan o rechazan como uno solo. Sin embargo, si las características no son similares / relacionadas, pruébelas por separado.

Finalmente, asegúrate de usar la automatización disponible, para que los equipos no estén esperando a otro equipo por nada. La mayoría de los servidores de compilación se pueden configurar para construir sucursales de solicitud de extracción, produciendo una compilación FeatureA+dev que puede ir al control de calidad para las pruebas de aceptación e integración. El desarrollador simplemente abre el PR (que también sirve como una revisión de código, si lo desea, y también sirve para indicar que la función está lista para la prueba), y una vez que el control de calidad se apaga, lo completa. Esto luego fusiona la rama en dev automáticamente. Pueden hacer lo mismo para UAT y master , creando PR para fusionar dev en UAT , y UAT en master .

Es posible que luego puedas reducir el número de sucursales y mantenerte con dev y master , más featureX . Deshágase de UAT , ya que ese rol es esencialmente servido por dev . El desarrollo real se realiza en featureX y la producción está en master . Implemente el nuevo código cada vez que se actualice master , o implemente lo que sea que esté en master cada vez que quiera lanzar.

    
respondido por el mmathis 12.02.2018 - 23:20

Lea otras preguntas en las etiquetas