De releases mensuales a semanales

Contexto

Trabajaba en el equipo que mantiene las apps móviles de una plataforma con unos 90 millones de usuarios al mes entre web y apps. Varios equipos de producto entregaban código a la misma app. Y la app salía a las tiendas una vez al mes, más o menos.

“Más o menos” era el problema.

Problema

Las fechas se movían. Alguna feature se colaba en producción “porque ya estaba lista”. Nadie tenía claro cuándo ni cómo salía una versión. Y cuando una release se atrasaba, los equipos metían más cosas para “aprovechar el viaje”. Resultado: releases grandes, tensas y poco frecuentes. Cuanto más grande la release, más miedo. Cuanto más miedo, menos releases.

Un círculo vicioso muy cómodo para nadie.

Qué decidimos (y qué descartamos)

Decidimos separar el cuándo del qué. Un tren de releases: fechas fijas, independientes del contenido. Lo que está listo, sube. Lo que no, espera al próximo tren.

Descartamos dos cosas. Primero, “llegar a semanal de golpe”. Un salto así sin automatización es pedirle a la gente que haga más veces lo que ya le duele. Segundo, la figura del héroe que “se encarga de la release”. Un proceso que depende de una persona no escala; se rota.

Cómo lo hicimos

Fuimos por escalones:

1. Tren quincenal. Fechas fijas, una rotación de “release captain” y una checklist: testing, changelog, validaciones y métricas después de publicar.
2. Automatizar lo repetitivo. Cut-off, subida de versión, merge-backs, tags y traducciones dejaron de ser pasos manuales. Un detalle que me gusta contar: el disparador de CI saltaba cada semana, y unos pasos de guarda decidían si ese día tocaba cortar o publicar. Cambiar de cadencia pasó a ser cambiar una regla, no rehacer el pipeline.
3. Feature flags. Separar el deploy de la liberación. Si algo no está listo, viaja apagado; no retrasa a nadie.
4. Alertas e informes después de cada release. Crash-free rate y métricas de rendimiento por versión, visibles para todos.
5. Semanal. Cuando el tren ya no daba miedo, acortamos el ciclo.

Una regla que repetí hasta el cansancio: cada paso tiene que dejar el proceso más aburrido. Si una release es un evento, algo está mal.

Resultado

Pasamos de una release mensual a una semanal. Los equipos dejaron de negociar fechas y empezaron a planificar contra un calendario conocido. El rollback y el hotfix dejaron de ser una improvisación y pasaron a ser un procedimiento documentado.

Lo conté en Commit Conf 2023 con una metáfora: de los caballos al tren, y del tren al Hyperloop. Y aclaré lo que vale la pena repetir acá: sin humo, sin reinventar nada, paso a paso.

Qué haría distinto

Mediría el tiempo de ciclo de punta a punta desde el primer día, no desde la mitad. Hicimos mejoras con buen olfato, pero a veces sin una línea base que me permitiera demostrar cuánto habíamos mejorado.

Y hablaría antes con QA. Acortar la cadencia le cambia el trabajo a quien prueba más que a nadie, y yo lo vi tarde. La regresión manual de un mes no entra en una semana. Hay que rediseñarla, no comprimirla.