Cuando comencé a utilizar git intentamos emplear también gitflow. Lo comentaba como algo factible en un artículo de 2012. En estos momentos y tras 9 años de trabajo con git, tengo que admitir que no emplearía gitflow, ¿quieres saber mis motivos?
En 2012 y 2013, comenzamos a intentar usar gitflow. El trabajo lo realizábamos en diferentes repositorios porque teníamos una infraestructura basada en microservicios para XMPP. Al principio resultaba un poco tedioso pero los comandos extra para git contenían ayuda y al final se crea un hábito. Está bien. No obstante, surgió un problema y pudimos observar un comportamiento extraño.
Cuanto más trabajábamos en hotfixes y más avanzaba el trabajo de nuevas features, más diferentes parecían las versiones de producción, pruebas y desarrollo. Es más, hubo algunos momentos de tener que forzar una actualización de master a testing y de testing a develop para asegurarnos de tener en cada entorno el código correcto.
En otra empresa posterior, en 2015, recuerdo que mantuve una conversación con un administrador de sistemas porque intenté implementar gitflow. El administrador de sistemas se dió cuenta de forma inmediata de las diferencias entre versiones y solicitó deshacer la implementación de gitflow.
El problema era claro. Esta empresa tenía un entorno de Continuous Integration muy bien construido. Cada elemento llevado a la rama master era desplegado en un entorno de test y se disparaban todas las pruebas. Si era validado de forma correcta, el mismo artefacto generado para test, se enviaba a producción.
El problema de gitflow, es la necesidad de mantener dos ramas diferentes para estos entornos, entonces el trabajo mezclado dentro de la rama de test puede tener características diferentes aún no llevadas a producción y sin embargo, con dependencia del código que sí se quiere llevar a producción. Los tests realizados en el código no tendrían valor porque no se ha probado el código exacto que estará en producción.
Esta situación podría haberse evitado realizando dos tipos de pruebas, una para el entorno de test y otra diferente para el entorno de producción. Cada cambio en uno u otro entorno dispararían sus respectivas pruebas. Pero si lo pensamos bien, esto implica mayor número de recursos y volviendo al caso de la primera empresa, la incertidumbre de saber si tenemos o no el mismo código en ambas ramas en un momento dado.
¿Y tú?, ¿Empleas Gitflow? ¿Has experimentado alguno de estos problemas? ¿Te has planteado utilizarlo? ¡Déjanos tu comentario!
