Z-Flow

Integración continua, flexibilidad y limpieza eficiente del historial: conoce el Z-Flow y avanza en la productividad con tu equipo de desarrollo.

Por Thauany Moedano – Cloud Architect y Back-End Software Developer en Zappts

El tema de hoy aquí en el blog es Git Workflow y voy a presentar un poco la solución Z-Flow, desarrollada por Zappts. ¡Vamos allá!

Bueno, cuando hablamos del trabajo en equipo de un equipo de desarrollo, no podemos dejar de mencionar el uso de una herramienta de versionado.

Nuestro amigo git es probablemente uno de los primeros sistemas de versionado de código que todo desarrollador conoce cuando empieza a trabajar en equipo, y aunque git es increíblemente potente y muy útil, aún se discute mucho sobre cómo utilizarlo.

Por lo tanto, si tienes esta duda, sigue leyendo este artículo porque voy a compartir contigo información importante sobre el tema.

Git Workflow

¿Cuál es la mejor forma de trabajar con git? ¿Cómo organizo las branches?

De estos cuestionamientos surgieron los workflows y es a través de ellos que podemos encontrar las respuestas que tanto buscamos.

Un workflow es un framework para la organización de branches.

El workflow dicta cómo deben ser organizadas y nombradas las branches y qué movimientos deben hacerse hasta la entrega del producto final.

Existen diversos modelos conocidos y probablemente ya hayas encontrado alguno.

Pero, con tantos frameworks ya disponibles y conocidos, ¿por qué crear un nuevo workflow?

Primero, es importante destacar que los modelos más antiguos no tienen en cuenta nuestro escenario actual de integración y entrega continua (esas palabras famosas: CI/CD).

¿Y los modelos más nuevos, como “GitHub Flow” o “Feature Branch Workflow“?

De hecho, realmente son geniales para CI/CD (incluso nos basamos en algunos conceptos básicos de GitHub Flow). Sin embargo, presentan una master branch y homolog (o release en algunos proyectos) muy contaminadas, y a veces con decenas o cientos de miles de commits, lo que imposibilita que cualquier expert entienda cuál fue la secuencia de entregas realizadas.

Esta enormidad de commits pasan a no servir para nada (excepto para confundir), además de hacer que el proceso de rollback sea muy complejo (para quien nunca ha pasado por esto, no quiere saber lo que es tener que hacer git revert y revert de revert para volver a poner las cosas en orden).

Aquí en Zappts ya nos hemos encontrado muchas veces con esta situación en proyectos propios y también de clientes. Por eso, pensamos en una nueva forma de organizar cómo entregar funcionalidades a producción.

Z-Flow – La solución Zappts de Git Workflow

Vamos allá: todo lo que hacemos cuando trabajamos en desarrollo de software está enfocado en entregas con calidad, ¿verdad?

Basándonos en esta premisa, creamos un modelo de workflow que dejara nuestra branch de desarrollo con todos los commits hechos por los desarrolladores (ellos son importantes allí), y nuestra branch de producción con el historial de entregas y no de commits de desarrollo, permitiendo también la administración de deploys por entregas específicas y no como un todo.

¡Así surgió el Z-Flow!

¿Qué necesito saber para aprovechar al máximo este artículo?

Para que estés en la misma página que nosotros y acompañes los dolores que pasamos antes de decidir pensar en el Z-Flow, sería importante que conocieras de:

• Git: que ya hayas trabajado en algún proyecto que use git como sistema de versionado de código. Si ya has pasado por los dolores de gestionar un git con muchos desarrolladores, proyecto grande, código que “desapareció de la nada” de tu branch, mejor aún.
• GitFlow: parte de la premisa de que todas las feature branches parten de Dev. Es decir, Dev necesita estar estable con todas las features que serán publicadas para homologación y posteriormente producción.
• GitHub Flow: parte de la premisa de que todas las feature branches parten de Master y que todas las feature branches pueden ser mergeadas en master por separado. Normalmente, en proyectos más grandes, existen branches intermedias (todas provenientes de master), que reciben individualmente la feature branch.
• Entrega Continua (CI/CD): usando los commits de las branches como fuente para ejecutar una pipeline de publicación automática. Cuando un commit se envía (pushed) a una branch, automáticamente se ejecuta un script que publica ese nuevo código en un entorno determinado.

Atención: si trabajas en desarrollo de software, ¡ven a formar parte de nuestro equipo! Consulta las vacantes y envía tu currículum hoy mismo.

Presentando el Z-Flow

Como se mencionó anteriormente, si implementas el Z-Flow en tu proyecto, tendrás una branch de producción MUY limpia, conteniendo solo el historial de entregas y siguiendo la cronología de entrega de cada feature, además de una branch de desarrollo que tenga todos los historiales de commits hechos por todos los desarrolladores.

Branches principales

El Z-Flow tiene cuatro branches principales:

• master
• develop
• qa
• homolog

La master es la branch de producción y siempre representa una versión estable de nuestro software.

En cuanto a develop, es en esta branch donde las nuevas features se van acumulando y el equipo de desarrollo tiene visibilidad de qué features ya han sido implementadas por otros desarrolladores.

Debido a que la branch de develop se actualiza con frecuencia, es la branch más susceptible a inestabilidades.

Ahora, presentemos dos nuevas branches que tal vez aún no conozcas: la qa y la homolog.

La branch de qa está dedicada al equipo de calidad. Es donde se ejecutan las pruebas por parte del equipo de calidad.

La branch de qa es más estable que la branch de develop, ya que los desarrolladores deben garantizar la estabilidad de su feature antes de pasarla a la fase de pruebas.

p.s: la branch qa es recomendable, pero no es obligatoria para que el Z-Flow funcione como lo imaginamos. Si tienes un equipo o proyecto pequeño, tal vez esta branch pueda prescindirse.

Y por último, tenemos la branch de homolog, donde están todas las features probadas por el equipo de QA, pero que aún necesitan ser homologadas por el equipo de negocio. Esta es la branch que entrega features a producción.

Importante: en algunos casos específicos de proyectos, es necesario incluir la branch Pré-Prod después de homolog. Este caso se tratará más adelante.

Z-Flow – Transitando entre branches

Para que el desarrollo ocurra de manera paralela y eficiente, usamos branches secundarias. Son ellas:

• feature branch
• delivery branch

Recordando que para cada feature desarrollada tendremos una feature branch y una delivery branch.

Para todas las transiciones entre branches, sean principales o secundarias, recomendamos seguir las buenas prácticas de git, al menos usando herramientas que soporten merge por Pull Request y designando usuarios independientes para hacer code review en cada Pull Request.

Feature Branch

Deriva de: master

Recibe el contenido de: los commits hechos por los desarrolladores de la feature

Entrega su contenido en: develop (–no-ff), qa (–no-ff)

Convención: feature/*

La feature branch es donde el desarrollador incorpora las nuevas funcionalidades del sistema.

Siempre deriva de master para garantizar que estamos trabajando sobre una versión estable de producción.

Todas las implementaciones de la feature deben hacerse en la feature branch, nunca directamente en develop o en otra branch.

Una vez que el desarrollo se finaliza, la feature debe ser entregada (mergeada) en modo no-fast-forward en develop para que el desarrollador pueda hacer pruebas integradas con otras funcionalidades incorporadas por otros equipos.

Después de hacer todas las implementaciones y cambios en la feature branch y garantizar la estabilidad de la feature en develop, el desarrollador puede mergear la feature branch en modo no-fast-forward en la branch qa para iniciar la fase de pruebas. Por lo tanto, nuestro flujo queda así:

git checkout master
git pull origin master
git checkout -b feature/mi-feature

**después de implementar cambios (git commits):
git checkout develop
git pull origin develop
git merge --no-ff feature/mi-feature
git push origin develop

**cuando la feature esté lista para pruebas:
git checkout qa
git pull origin qa
git merge --no-ff feature/mi-feature
git push origin qa

Delivery Branch

Deriva de: master

Recibe el contenido de: feature branch (–squash)

Entrega su contenido en: homolog (–no-ff)

Convención: delivery/*

Con el propósito de limpiar el historial de commits, la delivery branch sirve para reducir el historial de commits de una feature branch lista para entrega.

Entiende la delivery branch como siendo exactamente la feature branch, con el mínimo de commits posibles, los commits referentes a cada “entrega” de la feature.

Para lograr este objetivo, la delivery branch recibe el squash merge de su feature branch equivalente después de la aprobación de la feature en QA.

Así, la delivery branch queda con el mismo contenido que la feature branch (master + nueva funcionalidad), pero solo con un commit (el resultante del squash merge).

Sigue nuestro flujo:

git checkout master
git pull origin master
git checkout -b delivery/mi-feature
git merge --squash feature/mi-feature
git commit -m "delivery de feature mi-feature"

Homolog Branch

Deriva de: master

Recibe el contenido de: delivery branch (–no-ff)

Entrega su contenido en: master (–no-ff)

La branch de homolog recibirá todas las features que están probadas y listas para ser homologadas.

Para entregar el contenido de cada feature lista para ser homologada a homolog, la delivery branch (referente a cada feature) será mergeada en homolog.

El merge aquí ocurre en modo “no-ff” para que se cree un historial de entrega de la feature para homologación. Entonces, atención: es la delivery branch la que debe ser entregada para homologación.

p.s: la branch homolog solo queda con los commits referentes a cada entrega de feature hecha para homologación. ¡Al usar el Z-Flow, tienes en la branch homolog un historial limpio de todas las entregas de features para homologación!

git checkout homolog
git pull origin homolog
git merge --no-ff delivery/mi-feature
git push origin homolog

Master Branch

Recibe el contenido de: homolog (–no-ff)

Entrega su contenido: para creación de nuevas feature branches y delivery branches

¿Y cuándo se entregan las features en master?

Consideramos, para este flow, una entrega a producción como siendo exactamente lo que está homologado.

De esta forma, cuando llega el momento correcto, la branch master necesita ser una “copia” de la branch homolog.

Cuando un conjunto de features está homologado, basta con hacer merge en modo “no-ff” de homolog a master para actualizarla, haciendo que master sea una nueva versión estable.

git checkout master
git pull origin master
git merge --no-ff homolog
git push origin master

Así, podemos etiquetar la última versión estable cada vez que entregamos un conjunto de features.

p.s. 1: cuando sea necesario tener una branch “pré-prod”, sigue los pasos descritos aquí como ‘master’. Después de que pré-prod esté validado, sigue nuevamente estos pasos cambiando “homolog” por “pré-prod”.

p.s 2: la branch master solo queda con los commits referentes a cada entrega de feature hecha para homologación. Al usar el Z-Flow, tienes en la branch master un historial limpio de todas las entregas de features para homologación junto con un historial de todas las entregas hechas a producción.

¿Por qué necesitamos una delivery branch?

Pero, ¿por qué necesitamos crear una branch más si podríamos simplemente hacer squash merge de la feature directamente en homolog?

Realmente, esto se puede haciendo el flow mucho más simple. Entonces, ¿cuál es la razón de existencia de la delivery branch?

Nosotros en Zappts valoramos mucho el code review y siempre es importante que alguien apruebe nuestro código antes de que lo sometamos a una de las branches principales.

Al usar squash merge, debido a la forma en que las herramientas de code review usan git diff, se vuelve muy difícil entender las diferencias entre un commit y otro.

Por lo tanto, el propósito de crear una branch intermedia, solo para crear un squash merge (un commit único) de la feature branch, es para no perjudicar el code review entre otras branches.

El proceso es ciertamente un poco más laborioso, pero el esfuerzo vale la pena: por un pequeño costo (5 comandos de git), se obtiene un retorno enorme (inmensurable en algunos proyectos) de tener branches homolog y master limpias, con pocos commits cronológicamente organizados en forma de entregas.

Haríamos el doble (o más) por este resultado.

Lidiando con errores

¿Cómo manejarlo en Z-Flow cuando nuestra feature tiene errores?

La regla es simple: errores encontrados localmente (feature) o en las branches develop y qa se corrigen en la feature branch y se entregan nuevamente en develop y qa.

Si el error fue capturado en la branch homolog, debe ser corregido en la feature branch, replicado (squashed) a la delivery branch y entregado nuevamente en homolog.

Se entiende que la delivery branch quedará con algunos commits más (la primera entrega y la segunda entrega con el error corregido). Es exactamente lo que se busca: un historial limpio de entregas.

¿Y cuándo encontramos un error que ya está en producción? En este caso, creamos una branch específica para tratar el error, llamada hotfix.

Hotfix Branch

Deriva de: master

Entrega el contenido en: delivery/hotfix (–squash)

Convención: hotfix/*

La hotfix branch debe seguir el mismo flujo ya presentado en la feature branch, solo cambiando la convención de nombres. En este caso:

git checkout master
git pull origin master
git checkout -b hotfix/mi-hotfix

después de implementar cambios (git commits):
git checkout develop
git pull origin develop
git merge --no-ff hotfix/mi-hotfix
git push origin develop

**después de garantizar estabilidad del hotfix:
git checkout qa
git pull origin qa
git merge --no-ff hotfix/mi-hotfix
git push origin qa

Y de la misma forma que para una feature branch existe una delivery branch, para el hotfix también existe una delivery hotfix branch.

Delivery Hotfix Branch

Deriva de: master

Recibe el contenido de: hotfix (–squash)

Entrega el contenido en: homolog (–no-ff)

Convención: delivery/hotfix/*

Y el flujo también sigue el mismo que una delivery branch, solo cambiando la convención de nombres:

git checkout master
git pull origin master
git checkout -b delivery/hotfix/mi-hotfix
git merge --squash hotfix/mi-hotfix
git commit -m "delivery del hotfix mi-hotfix"
git push origin delivery/hotfix/mi-hotfix

Vale resaltar que debido a la urgencia que el hotfix puede presentar, es posible saltar pasos en el Z-Flow y entregar directamente un hotfix en qa o crear directamente una delivery branch para entrega en homolog/master.

Integración Continua y Despliegue Continuo

El Z-Flow garantiza integración continua ya que las branches se incorporan juntas en todas las branches principales.

Con Z-Flow siempre se están probando features integradas unas con otras. Al pasar por la branch de qa, el Z-Flow garantiza que una nueva feature no rompa las demás ya entregadas en producción en la branch master.

Hay casos en que es necesario entregar features prontamente o antes de un conjunto de funcionalidades. En estos, algunos pasos del Z-Flow pueden saltarse y la delivery branch puede ser mergeada directamente en master, ya que la delivery branch ya deriva de master.

Esto garantiza que todas las delivery branches siempre contengan: master (entorno de producción estable) + feature (nueva funcionalidad).

Por lo tanto, Z-Flow es un modelo flexible que permite tanto la entrega de un conjunto de features ya integradas como la división de entregas en paquetes separados.

Branch de producción más estable

Como la feature branch debe pasar por las branches de develop y qa (y es intensamente probada), es poco probable que la branch de producción se vuelva inestable.

Esto ocurre porque solo features que ya contienen master probadas y listas se entregan a producción.

O sea, el escenario de master + nueva implementación ya es simulado y probado desde develop y qa.

Historial más limpio

Como la delivery branch siempre es un squash de una feature branch y se entrega en homolog y master, el Z-Flow garantiza que en branches finales el historial de commits será mucho más limpio, considerando así un historial de entregas y no un historial de desarrollo.

Usando las delivery branches, es fácil entender la cronología de entregas, ya que cada delivery branch generalmente está compuesta de dos commits (un commit de la implementación y un commit del merge).

¡Y ya que has llegado hasta aquí con nosotros, debes estar interesado en saber cómo funciona el Z-Flow en la realidad, ¿verdad? ¡Entonces, vamos allá!

Mira la imagen a continuación para ver un ejemplo de cómo el historial se vuelve más limpio y claro sobre las entregas en las branches homolog y master, y cómo el historial está completo con todos los commits de desarrollo en las branches develop y qa, cumpliendo los objetivos principales del Z-Flow.

Hay dos formas de analizar esta imagen:

1. Con foco en las branches: analiza solo las branches, de arriba hacia abajo, olvidando las branches de al lado. Mira cómo queda el historial de commits de una sola branch. Entiende qué pasó con la branch, evolutivamente. Recuerda mirar con una perspectiva de desarrollador para las branches de develop y qa y con la perspectiva de negocio para las branches de homolog y master.

2. Con foco en el flujo: sigue el flujo de merges. Cuando el merge es tipo no-ff, arrastra el historial de commits de la branch origen. Cuando el merge es tipo squash, resume todos los commits de la branch en un único commit.

Conclusión

El Z-Flow es una alternativa a los modelos de workflow. Trae flexibilidad y garantiza CI/CD mientras limpia el historial de commits, además de mantener una branch de producción estable.

Entonces, ¿listo para agregar el Z-Flow a tu catálogo de workflows? ¿Listo para usar el Z-Flow en tu proyecto?

Si tu empresa necesita ayuda para estructurar procesos de desarrollo, ¡cuenta con nosotros! Aceleraremos tus resultados con soluciones productivas como el Z-Flow. ¡Habla ahora mismo con nuestros especialistas!

Y si eres desarrollador(a), míra esto: ¿qué tal venir a trabajar a Zappts?

Aquí encontrarás el MEJOR ambiente para desarrollar tus habilidades, exponer ideas y aprender muchas cosas geniales.

Hemos construido un espacio increíble de trabajo y diversión, que respeta la diversidad y brinda condiciones para que todos puedan dejar su marca en nuestra historia.

¡Ven a conocer las vacantes, trabajar y aprender con nosotros: https://zappts.com/trabalhe-conosco/

Hasta el próximo artículo