¿Cuáles son las prácticas recomendadas de GitLab Flow?

Cuando los equipos de desarrollo de software se apresuran a acelerar la entrega, pueden terminar con flujos de trabajo desordenados o complejos. Las organizaciones que han realizado la transición desde otro sistema de control de versiones son especialmente propensas a lidiar con procesos desafiantes que pueden ralentizar el desarrollo. Cuando los equipos usan GitLab Flow, pueden usar el desarrollo impulsado por funcionalidades y las ramas de funcionalidades con seguimiento de tickets para garantizar que todos los miembros del equipo trabajen de manera eficiente. Mediante el uso de estos consejos de GitLab Flow, los equipos de desarrollo de software pueden simplificar el proceso y producir un resultado más eficiente y limpio.

El uso de ramas de funcionalidades es una forma sencilla de desarrollar y mantener limpio el código fuente. Si, por ejemplo, un equipo hizo la transición recientemente a Git desde SVN, estará acostumbrado a un flujo de trabajo basado en troncales. Al usar Git, los desarrolladores deben crear una rama para lo que sea en lo que estén trabajando a fin de que los contribuidores puedan iniciar fácilmente el proceso de revisión de código antes de fusionar.

Algunos desarrolladores configuran su CI para que solo realice pruebas sobre lo que se fusionó con la rama main, pero esto es demasiado tarde en el ciclo de vida de desarrollo del software. Todos, desde los desarrolladores hasta los gerentes de producto, deben tener la confianza de que las pruebas de la rama main siempre son exitosas. Es ineficiente que los desarrolladores tengan que probar la rama main antes de comenzar a desarrollar nuevas funcionalidades.

Al trabajar en una rama feature y agregar nuevas confirmaciones, ejecute las pruebas de inmediato. Si las pruebas demoran mucho tiempo, intente ejecutarlas en paralelo. Haga esto del lado del servidor en las solicitudes de fusión y ejecute el conjunto de pruebas completo. Si hay un conjunto de pruebas para el desarrollo y otro solo para las nuevas versiones, es recomendable configurar las pruebas [en paralelo] y ejecutarlas todas al mismo tiempo.

No espere para probar todo al final de una semana o proyecto. Las revisiones de código deben realizarse lo antes posible, ya que es más probable que los desarrolladores identifiquen problemas que podrían causar tickets más adelante en el ciclo de vida. Dado que encontrarán los problemas antes, les resultará más fácil crear soluciones.

Si los desarrolladores no desean implementar la rama main cada vez, pueden crear la rama production. En lugar de usar un script o hacerlo de manera manual, los equipos pueden usar la automatización o tener una rama específica que desencadene una implementación de producción.

Se recomienda que los desarrolladores usen tags para que la CI realice una acción en lugar de que cambie el repositorio. Si los equipos requieren métricas detalladas, deben tener un informe del servidor que detalle las nuevas versiones.

Cada etiqueta debe crear un nuevo lanzamiento. Esta práctica garantiza un entorno de desarrollo limpio y eficiente.

Al hacer push a una rama pública, los desarrolladores no deben hacer rebase, porque eso dificulta la identificación de la mejora y los resultados de las pruebas durante el cherry pick. A veces, este consejo se puede ignorar al pedirle a alguien que haga squash y rebase al final de un proceso de revisión de código para que sea más fácil revertirlo. Sin embargo, en general, la pauta es la siguiente: el código debe estar limpio y el historial debe ser realista.

Este consejo evita ramas largas. Los desarrolladores comprueban la rama main, crean una funcionalidad, crean una solicitud de fusión y se dirigen a main de nuevo. Deben hacer una revisión completa antes de realizar la fusión y eliminar cualquier etapa intermedia.

Después de identificar un error, una acción problemática que alguien podría tomar es corregirlo en la versión recién lanzada y no corregirlo en main. Para evitarlo, los desarrolladores siempre deben realizar las correcciones haciendo push al cambio en main, y luego hacer el cherry pick de este cambio en otra rama patch-release.

Los desarrolladores no solo deben indicar lo que hicieron, sino también por qué lo hicieron. Una táctica aún más útil es explicar por qué se eligió esta opción en lugar de otras para ayudar a los futuros contribuidores a comprender el proceso de desarrollo. Escribir mensajes de confirmación descriptivos es útil para las revisiones de código y el desarrollo futuro.