Proceso de gestión de releases para publicar a menudo
8 min de lectura
Un proceso de gestión de releases es el conjunto de pasos que lleva un cambio desde “fusionado” hasta “en producción y explicado a las personas a las que afecta”. Para un equipo que publica a menudo, se reduce a siete pasos: planificar el alcance, aislar el cambio, compilar y probar, aprobar, desplegar y verificar, comunicar, y revisar. Cada paso necesita un responsable con nombre y un criterio de salida, o deja de ocurrir sin que nadie lo note.
Esta guía supone un equipo de 5 a 50 ingenieros que despliegan cada semana o cada día y quieren que el proceso no estorbe.
| Paso | Responsable | Criterios de salida |
|---|---|---|
| 1. Planificar el alcance | Producto o tech lead | La lista de cambios de esta release está escrita, y lo arriesgado está marcado |
| 2. Rama o flag | El ingeniero dueño del cambio | El trabajo está en una rama de vida corta o tras un flag, para que main siga siendo publicable |
| 3. Compilar y probar | CI, con el autor de guardia para los fallos | Pipeline en verde sobre el commit exacto que se va a publicar |
| 4. Aprobar | Revisor, más el release manager en cambios arriesgados | Revisión hecha, vía de rollback nombrada, decisión de seguir o no registrada |
| 5. Desplegar y verificar | Release manager o ingeniero de guardia | Desplegado, smoke checks superados, tasa de errores y latencia iguales a la referencia previa |
| 6. Comunicar | Quien entiende el cambio, editado por alguien que no | Notas de versión publicadas donde las leen los usuarios, soporte y ventas informados |
| 7. Revisar | Release manager | Métricas leídas, todo lo que salió mal tiene un responsable y una solución |
¿Qué es el proceso de gestión de releases?
Es el camino repetible que sigue un cambio para llegar a los usuarios: alcance, compilación, pruebas, aprobación, despliegue, verificación, anuncio y balance. Escribirlo sirve para que cada release siga el mismo camino, de modo que una persona de vacaciones, alguien recién incorporado o un ingeniero de guardia a las 2 de la madrugada puedan ejecutarlo sin preguntar a nadie cómo funciona.
¿Cuáles son los distintos tipos de gestión de releases?
Hay tres tipos prácticos: despliegue continuo, releases programadas y gestión de cambios regulada. Se diferencian en cuánto ocurre antes de una release y cuánto está automatizado. El despliegue continuo publica cada cambio fusionado, las releases programadas agrupan cambios en un tren, y la gestión de cambios regulada añade aprobación formal y un rastro de auditoría.
| Despliegue continuo | Releases programadas | Gestión de cambios regulada o ITIL | |
|---|---|---|---|
| Unidad de release | Un pull request fusionado | Un lote, semanal o quincenal | Una solicitud de cambio |
| Paso de alcance | Implícito, la fusión es el alcance | Reunión de planificación de la release | Registro de cambio con clasificación de riesgo |
| Aprobación | Revisión de código más comprobaciones automáticas | El release manager aprueba el lote | Comité asesor de cambios o aprobador delegado |
| Control de riesgo | Feature flags, canarios, rollback rápido | Periodo en staging, release candidate | Plan de marcha atrás documentado, ventana de mantenimiento |
| Cadencia típica | Muchas al día | Semanal a mensual | La fija el calendario de cambios |
| Punto débil | Nadie cuenta a los usuarios qué cambió | Los lotes grandes esconden el cambio que rompió algo | El tiempo de proceso eclipsa el propio cambio |
La mayoría de los equipos son una mezcla. Un producto SaaS puede desplegar de forma continua mientras su app móvil sale en un tren semanal, y el único servicio de pagos que importa a los auditores sigue un registro de cambios formal. Elige el tipo por servicio, no por empresa. Cuando los cambios solo se exponen de forma gradual, la release y el anuncio pasan a ser eventos separados, el caso que se trata en notas de versión con feature flags.
¿Cuáles son las responsabilidades de un release manager?
Un release manager es dueño del camino que sigue un cambio hasta producción. Lleva el calendario de releases, decide si un cambio está listo, ejecuta o supervisa el despliegue, toma la decisión de rollback, se asegura de que se avise a los usuarios y dirige la revisión posterior.
Antes de la release, confirma el alcance y comprueba que todo cambio arriesgado tiene una vía de rollback. Durante ella, ejecuta la checklist de despliegue, vigila los primeros minutos de las métricas de producción y decide el rollback pronto. Después confirma que las notas salieron y anota qué corregir en el proceso.
En un equipo pequeño, rota el rol cada semana y escribe la checklist para que nadie necesite conocimiento tribal. Un monorepo con muchos paquetes que se publican de forma independiente suele necesitar un responsable de release por paquete, o el rol se convierte en un cuello de botella.
¿Cuáles son los KPI clave de la gestión de releases?
Sigue las métricas de entrega de software de DORA y añade una propia: cuánto tardan en avisar a los usuarios. La investigación de DORA identifica cinco métricas, divididas en rendimiento (tiempo de entrega de cambios, frecuencia de despliegue, tiempo de recuperación de despliegues fallidos) e inestabilidad (tasa de fallos de cambios, tasa de retrabajo de despliegues).
La guía de DORA las define en términos sencillos (dora.dev, software delivery metrics):
| KPI | Qué mide | A qué estar atento |
|---|---|---|
| Tiempo de entrega de cambios | Tiempo desde el commit en el control de versiones hasta el despliegue en producción | Un número creciente suele indicar colas en la revisión o la aprobación |
| Frecuencia de despliegue | Cada cuánto despliegas, o el tiempo entre despliegues | Si la frecuencia cae, los lotes están creciendo |
| Tiempo de recuperación de despliegues fallidos | Tiempo para recuperarse de un despliegue que requiere intervención inmediata | Aquí aparecen los problemas de rollback y de alertas |
| Tasa de fallos de cambios | Proporción de despliegues que requieren un rollback o un hotfix | Sube cuando los lotes son demasiado grandes o las pruebas escasas |
| Tasa de retrabajo de despliegues | Proporción de despliegues no planificados y causados por un incidente en producción | Señal de que las correcciones salen más rápido que las lecciones |
| Tiempo hasta avisar a los usuarios | Minutos desde el despliegue en producción hasta una nota publicada de cara al usuario | Mídelo tú mismo, ningún marco lo ofrece |
El material más antiguo lista cuatro métricas clave y llama a la recuperación “time to restore”. La guía actual usa las cinco de arriba.
La misma guía advierte contra tratarlas como objetivos. Fijar una meta como “todo se despliega varias veces al día a fin de año” invita a los equipos a manipular las cifras, y las métricas están pensadas para leerse por aplicación o servicio, no mezcladas en toda la empresa. Su consejo práctico para mejorarlas todas es reducir el tamaño de cada cambio, porque los cambios pequeños son más fáciles de revisar, de pasar por el pipeline y de recuperar.
¿Cómo encaja la comunicación de la release en el proceso de gestión de releases?
Es el paso seis, y tiene un responsable y un criterio de salida como todos los demás: notas publicadas donde las leen los usuarios, y los equipos internos informados. Es el paso que los equipos más omiten, porque las herramientas de despliegue informan de éxito en el instante en que el código está en producción.
La forma más barata de mantener este paso en plazo es escribir la entrada cuando el cambio se fusiona, no cuando se publica la release. El pull request ya contiene el título, el autor, el issue enlazado y el contexto. Un borrador construido a partir de él se edita, no se escribe de memoria una semana después. Esa es la idea detrás de la automatización de changelog: derivar un borrador al fusionar, retenerlo hasta que una persona lo apruebe y luego publicarlo en todas partes desde una sola fuente. Changeloop funciona así: redacta entradas a partir de pull requests fusionados con IA y las retiene para su aprobación antes de publicar nada.
Conviene prever dos variaciones. Soporte y ventas necesitan una nota distinta de la de los clientes, para lo que sirven las notas de release internas. Una release provocada por un incidente no tiene tiempo para el ciclo normal de redacción, así que ten lista una plantilla corta, como se describe en notas de versión de emergencia. La plantilla de notas de versión te da una forma de partida para la versión de cara al cliente.
¿Cómo mantienes el proceso ligero?
Automatiza todo criterio de salida que una máquina pueda comprobar, y reserva a las personas para los juicios. Un pipeline en verde, una marca de despliegue en los paneles y una entrada de changelog en borrador por cada pull request fusionado se pueden comprobar. Que un plan de rollback sea creíble, o que las notas tengan sentido para un cliente, requiere a una persona.
Para probar el proceso, elige una release del mes pasado y pregunta si alguien ajeno al equipo podría saber, solo por el registro escrito, qué se publicó, quién lo aprobó, cómo se verificó y cuándo se avisó a los usuarios. Cualquier hueco es tu próxima mejora.
FAQ
¿Cuál es la diferencia entre la gestión de releases y la gestión de cambios? La gestión de releases consigue que un conjunto de cambios se compile, pruebe, despliegue y anuncie. La gestión de cambios, en el sentido de ITIL, es el proceso de aprobación y de riesgo alrededor de cada cambio. Los equipos que publican a menudo integran la aprobación en la revisión de código y las comprobaciones automáticas.
¿Con qué frecuencia deberíamos publicar? Tan a menudo como permitan tus pruebas y tu vía de rollback, que para muchos equipos web es a diario o más. La recomendación de DORA es reducir el tamaño de cada cambio, ya que los cambios pequeños son más fáciles de revisar y de recuperar.
¿Necesitan los equipos pequeños un release manager? Necesitan las responsabilidades, pero no necesariamente el título. Rota el rol entre ingenieros, da a quien esté de turno una checklist escrita y asegúrate de que alguien es dueño de cada uno de los siete pasos.
¿Qué debe incluir una checklist de release? Alcance confirmado, pipeline en verde sobre el commit que se publica, vía de rollback nombrada, aprobación registrada, smoke checks tras el despliegue, métricas comparadas con la referencia, notas de versión publicadas, soporte informado y una revisión programada. Mantenla en una página.
Las afirmaciones técnicas de este artículo no se han revisado de forma independiente. Si algo está mal, avísanos y lo corregiremos.