De releases bimestrales a semanales
Cómo transformamos nuestra forma de entregar software en Macro Securities
Cuando llegué hace un año a Macro Securities, utilizábamos un modelo de releases muy común en la industria: Se hacía release management, planeando releases en base a nuevas funcionalidades, lo que generaba que muchos cambios se acumulen. No es que este modelo esté mal en sí, de hecho, muchas fintech utilizan este modelo. Pero en nuestro caso, donde requerimos velocidad y feedback continuo, necesitábamos cambiar el modelo.
El problema con los releases grandes
Los releases planificados tenían los siguientes problemas.
Se acumulaban muchos cambios
Al acumularse muchos cambios, los releases se convertían en actividades muy riesgosas. Había que controlar muchos cambios en muchos microservicios. Esto eran:
- Nuevos feature flags
- Nuevas variables de entorno
- Cambios de base de datos
- Cambios en interfaces
Los puntos de falla eran muchísimos y había releases que se extendían por varias horas.
Los hotfixes eran muy dolorosos
Cuando había un problema urgente en producción y había que salir con un hotfix, el context switch era enorme.
- Había que hacer el fix primero en un branch de release que podía estar muy desactualizado respecto del código principal en el branch main.
- Luego había que pasar de alguna forma el cambio al branch main, y en varias ocasiones el código era tan distinto que el fix en sí era muy diferente a lo que se había implementado en el release branch.
El desarrollador que tenía que hacer el hotfix perdía mucho tiempo haciendo este cambio de contexto, ya que tenía que volver a recordar el estado del código en ese momento y después volver a main e interpretar el fix para el nuevo estado del código
GitFlow sumaba complejidad
GitFlow, la metodología en la que hay varios branches que representan a los destinos ambientes de prueba, generaba muchísima fricción en el proceso. El código tenía demasiados estados y generaba más context switches para los desarrolladores.
La decisión de cambiar
Todo esto me llevó a tomar la decisión de cambiar lo antes posible. No podía cambiar todo de una vez, pero la dirección estratégica estaba clara. Yo venía de un background de CI/CD con trunk-based development, y sabía que existía una mejor forma de hacer las cosas. La dirección estaba alineada con dos de nuestros principios de ingeniería: Continuous Delivery y Lotes Chicos.
Lo primero que hice fue explicarle al equipo los problemas que teníamos y hacia dónde queríamos ir: CI/CD con trunk-based development. La idea central es simple: una feature terminada va a producción. La planificación del release se hace por feature y es parte del desarrollo de la misma.
El segundo paso fue eliminar GitFlow inmediatamente. No hubo transición gradual. GitFlow generaba demasiados problemas y lo quitamos de una vez. Pasamos a trabajar únicamente con el branch main y short-lived feature branches, es decir, branches que duran lo que dura el desarrollo de la feature.
El tercer paso fue plantear un intermedio realista: releases semanales. Este paso fue clave para lograr el cambio de disciplina en el equipo. La feature se desarrolla completamente en el feature branch y se diseña para que como mucho su desarrollo dure un sprint de dos semanas. Esto nos daba un ritmo predecible y manejable mientras el equipo se acostumbraba al nuevo modelo.
Dónde estamos hoy
Hace ya varios meses que implementamos la metodología de releases semanales y puedo decir que han sido un éxito rotundo:
- Los releases pasaron de tomar horas a tomar 15 minutos. Incluso un release de alto riesgo como la migración de Apache Kafka on-premise a su versión SaaS, un cambio que afectaba la infraestructura central de mensajería, se completó sin problemas en un release semanal estándar.
- Ya no tenemos el problema de los context switch para los hotfixes. Los hotfixes son cambios pequeños que pueden salir directamente del branch main, ya que main es el único branch general y siempre listo para poder ir a producción.
- Aumentó mucho más la colaboración entre Desarrollo y QA, ya que todo el ciclo de desarrollo y testing se hace en el feature branch, permitiendo que QA sea parte del desarrollo, en lugar de un paso al final de todo.
La recepción del equipo
El equipo recibió con muchísimo entusiasmo la decisión de cambiar el modelo de releases. Hubo fricciones respecto de cómo íbamos a lograrlo y los problemas que había que enfrentar. Surgieron preguntas respecto a cómo manejaríamos las regresiones de QA antes de los releases, ya que demoran bastante tiempo y requieren de servicios externos. Pero lo que yo traté de inspirar en el equipo es que los desafíos para lograr nuestro objetivo no eran cosas que nos bloqueaban, sino problemas a solucionar. Les pedí que tengamos mente ingenieril y que encaremos cada desafío para encontrar la solución y no nos quedemos en el estado actual.
Lo que viene
El siguiente paso es madurar mucho más nuestro proceso de regresión, para poder hacer releases on demand, es decir, cada vez que una feature se termina, se envía a producción. Para eso estamos aprovechando el uso de agentes de IA que automaticen aún más nuestros releases, a través de la generación de guías de release automatizadas, algo que voy a comentar en un futuro post.
Cierre
Esta transformación no fue un evento aislado. Fue parte de un cambio más profundo en nuestra cultura de ingeniería, que reflejamos en nuestro manifiesto de principios.
Estamos muy contentos con el rumbo que estamos tomando en cuanto a la metodología de desarrollo y particularmente la forma en que manejamos los releases. Sabemos que aún hay mucho trabajo por hacer y que nos enfrentaremos con problemas que quizás no habíamos anticipado. Pero de eso se trata la ingeniería, de resolver problemas reales con las herramientas que tenemos a nuestra disposición. No cambiamos porque algo estuviera roto, cambiamos porque queríamos entregar mejor y más rápido. Y es por eso que seguro sigamos cambiando, porque siempre hay formas de mejorar lo que hacemos.
¿Cómo manejan los releases en tu equipo? Me encantaría saber si pasaron por una transformación similar.