Diagrama de flujo del proceso de release de software
Diagrama del proceso de release y despliegue de software: congelación del alcance, puerta de pruebas automáticas, preproducción y UAT, aprobación go/no-go, despliegue, rollback y hotfix.
Cómo funciona
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.
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.
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.
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.
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.
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.