Diagrama de flujo del proceso de release de software

¿Qué es diagrama de flujo del proceso de release de software?

Un proceso de release de software es el conjunto de puertas que hay entre una build con el código completo y un sistema estable en producción. Los pasos en sí resultan familiares (crear una rama, compilarla, probarla, publicarla), pero el valor de escribir el proceso está en las puertas: el punto en el que el alcance deja de cambiar, el punto en el que una suite de pruebas en rojo devuelve el trabajo a desarrollo en lugar de dejarlo avanzar, el punto en el que alguien con autoridad para hacerlo dice adelante, y el punto en el que una release mala se revierte en vez de discutirse. Cada puerta deja constancia de qué llevaba la release, qué se probó, quién la aprobó y qué pasó después de publicarla.

La mayoría de los problemas de release son problemas de traspaso, no de ingeniería. Se corta una rama con tres merges todavía en el aire, así que nadie puede decir qué hay realmente en la build. QA lanza el paquete de regresión contra un entorno de preproducción que se separó de producción hace meses. La decisión go/no-go se toma en una videollamada sin criterios escritos, y gana la opinión más ruidosa. Una release sale a última hora de la tarde sin un periodo de observación acordado, y la primera señal de problemas es el correo de un cliente a la mañana siguiente. Dibujar el flujo por carriles hace explícito cada traspaso y enseña quién tiene la release en la mano en cada momento.

Esta plantilla es un flujo de release real repartido en cinco carriles (Desarrollo, QA, Responsable de release, Operaciones y Product owner) y cinco fases, de la congelación del alcance al cierre. Incluye los tres bucles que los equipos suelen dejar sin dibujar: la puerta de pruebas automáticas que devuelve los fallos a la rama de release, la decisión no-go que manda la release a corrección en lugar de a producción, y la vía de hotfix que permite que un defecto posterior a la publicación vuelva a entrar por despliegue y verificación sin que nadie se invente un proceso paralelo.

Qué cubre este diagrama de flujo

En esta plantilla

• Alcance y rama en los tres primeros carriles: código completo en Desarrollo, QA confirmando el alcance y los criterios de entrada de las pruebas, y el responsable de release congelando el alcance y creando la rama de release
• La puerta de pruebas automáticas: Desarrollo compila y ejecuta las pruebas, y QA es dueño de la decisión «¿Pasan las pruebas automáticas?», que manda los fallos a «Corregir defectos en la rama de release» y de vuelta a la compilación en lugar de dejarlos avanzar
• Preproducción y UAT como tres traspasos distintos: Operaciones despliega la build en preproducción, QA ejecuta las pruebas de regresión y el product owner ejecuta el UAT y registra la aceptación
• La aprobación entendida como expediente más decisión: el responsable de release reúne el expediente de preparación, el product owner aprueba la release para producción y la decisión «¿Go o no-go?» la publica o la devuelve al paso de corrección de defectos
• La ruta de producción en el carril de Operaciones: desplegar en la ventana de publicación, ejecutar pruebas de humo y una decisión «¿La release es estable?» que envía una release con fallos a «Revertir a la versión anterior» y de nuevo a la corrección de defectos
• Seguimiento y cierre: un periodo de observación definido, una decisión «¿Defecto en producción?» que alimenta el bucle de hotfix a través del despliegue y las pruebas de humo, y un paso final que publica las notas de versión y cierra la release

Cuándo usar esta plantilla

• Estás escribiendo o reescribiendo el procedimiento de release de un equipo que hasta ahora publicaba por costumbre y por hilos de chat, y necesita una imagen acordada antes de codificarla en un pipeline
• Incorporáis a desarrolladores, analistas de QA o personal de guardia que necesitan saber qué puerta les pertenece y qué pasa aguas abajo si la retienen
• Queréis zanjar quién toma de verdad la decisión go/no-go, y con qué criterios, antes de que la próxima release fuerce la discusión
• Tenéis que responder a un cuestionario de seguridad de un cliente o a una auditoría interna sobre cómo se prueban, aprueban y revierten los cambios
• Revisáis el proceso después de una release mala, para que la conversación gire sobre qué puerta se saltó y no sobre una reconstrucción de memoria

Cómo funciona

1. Renombra los carriles con vuestros roles reales

   Sustituye Desarrollo, QA, Responsable de release, Operaciones y Product owner por los roles que tenéis de verdad. Muchos equipos no tienen un responsable de release dedicado; en ese caso funde ese carril con la dirección técnica en vez de dejar una banda vacía. Si no hay un equipo de operaciones separado, mete el despliegue dentro de Desarrollo y dilo en el diagrama.

2. Define qué significa la congelación del alcance

   Escribe vuestra regla de congelación junto al paso de creación de rama: qué puede seguir entrando en la rama después del corte, quién autoriza una excepción y cómo se etiqueta la rama. Anota el commit del que salió, porque es lo que hace reproducible la build y permite generar las notas de versión a partir del diff.

3. Define qué significa «pasar» en cada puerta de pruebas

   La decisión «¿Pasan las pruebas automáticas?» vale lo que valga su definición. Indica qué suites deben estar en verde, qué umbral de flakiness o de cobertura aceptáis y quién puede saltarse una build en rojo. Haz lo mismo con el paquete de regresión en preproducción y con el UAT, para que el product owner sepa qué está firmando.

4. Escribe los criterios de go/no-go antes de necesitarlos

   Sustituye la decisión genérica por vuestra propia lista: sin defectos críticos abiertos, rollback ensayado, guardia confirmada, equipos dependientes avisados y una hora límite declarada. Nombra quién preside la llamada y quién puede vetar. Acordar esto con una release ya esperando es justo la manera de aprobar releases malas.

5. Fija el disparador de rollback, el periodo de observación y la ruta de hotfix

   Di qué hace que «¿La release es estable?» responda que no: una tasa de error concreta, un umbral de latencia o una prueba de humo fallida, no una impresión. Fija cuánto dura la observación y qué se vigila. Y decide qué aprobación necesita un hotfix, quién puede autorizarlo fuera de horario y cómo se integra de vuelta en la rama principal, porque una corrección que solo vive en la rama de release es una fuente clásica de la siguiente regresión.

6. Publícalo y mantén una sola versión vigente

   Comparte el diagrama donde ocurre el trabajo, junto a la checklist de release o en el runbook, y recoge la firma de las personas que aparecen en él. Guarda las versiones anteriores para poder enseñar cuándo cambió el procedimiento y por qué, y revísalo después de cualquier release que haya salido mal.

Preguntas frecuentes

¿Cuáles son las fases de un proceso de release de software?

Cinco fases cubren a casi todos los equipos. Primera, alcance y rama: acordar qué entra en la release, confirmar los criterios de entrada de las pruebas, congelar el alcance y crear la rama. Segunda, compilación y pruebas: generar una release candidate, ejecutar la suite automática y devolver los fallos a la rama en lugar de dejarlos avanzar. Tercera, preproducción y UAT: desplegar en un entorno de preproducción, ejecutar las pruebas de regresión y obtener la aceptación del product owner. Cuarta, aprobación: reunir el expediente de preparación y tomar una decisión go/no-go explícita. Quinta, publicación y seguimiento: desplegar en la ventana acordada, ejecutar pruebas de humo, vigilar durante un periodo definido y después publicar las notas de versión y cerrar la release.

¿Qué diferencia hay entre el proceso de release y el pipeline de despliegue?

El pipeline de despliegue es la automatización: compila, prueba y publica el código cuando se dispara. El proceso de release son las decisiones que lo rodean: quién acordó el alcance, quién confirmó que las pruebas eran significativas, quién aprobó producción, qué pasa cuando la release sale mal y cuándo puede el equipo bajar la guardia. Un pipeline maduro elimina pasos manuales, pero no elimina las decisiones. Este diagrama las dibuja a propósito como decisiones, para que veas cuáles ya impone vuestro pipeline y cuáles siguen dependiendo de que alguien se acuerde.

¿Quién debe tomar la decisión go/no-go y en qué debe basarse?

Debe presidirla una persona con nombre, normalmente el responsable de release o quien sea dueño de producción, con la aprobación del product owner ya registrada como entrada y no debatida en la llamada. Básala en criterios escritos antes de la release: sin defectos críticos abiertos, regresión y UAT completos, rollback ensayado, guardia confirmada y equipos dependientes avisados. Registra quién asistió y qué se decidió, no solo el resultado. Si os auditan bajo SOC 2, el criterio relevante es CC8.1, que espera que los cambios estén autorizados, probados, aprobados y documentados; el expediente de preparación y el rastro de aprobación son lo que lo evidencia, y el diagrama muestra dónde se producen.

¿Cómo se gestionan los hotfix sin saltarse el proceso de release?

Un hotfix comprime el proceso, no se lo salta. En esta plantilla, un defecto encontrado durante el periodo de observación va a «Compilar y probar un hotfix» en el carril de Desarrollo, y después vuelve a entrar por el despliegue y pasa por las mismas pruebas de humo en producción y la misma comprobación «¿La release es estable?» que una release planificada. Lo que cambia es la velocidad de aprobación, no la verificación. Dos reglas lo mantienen honesto: acordar por adelantado quién puede autorizar un hotfix fuera de horario, e integrar la corrección en la rama principal el mismo día, porque una corrección que solo existe en la rama de release reaparece como regresión en la siguiente.