Diagrama del proceso de despliegue de software a producción

¿Qué es diagrama del proceso de despliegue de software a producción?

Un proceso de despliegue de software es la mecánica de poner un artefacto compilado sobre infraestructura en funcionamiento. Empieza en una fusión de código y termina con una versión desplegada al cien por cien o con una vuelta atrás a la anterior. Eso lo hace deliberadamente más estrecho que la gestión de releases, que decide qué entra en una entrega, cuándo se congela el alcance y si la organización está lista para publicar. La gestión de releases responde al «si» y al «qué»; el despliegue responde al «cómo». Si el diagrama que necesitas contiene congelación de alcance, aceptación de usuario y una reunión de go/no-go, lo que buscas es el proceso de release. Si contiene una versión de artefacto, un registro, un desvío de tráfico y un disparador de rollback, estás en el sitio correcto. Tampoco es gestión de cambios de TI: la ventana de cambio y su aprobación aparecen aquí como dos pasos, no como el tema, porque el diagrama asume que ya existe una vía de aprobación y muestra dónde espera el despliegue.

Casi todos los incidentes de despliegue se remontan a un puñado de supuestos que nadie dibujó. El artefacto se recompila por entorno, así que lo que pasó las pruebas no es exactamente lo que llegó a producción. La preproducción se separó de la configuración real hace meses, de modo que unas pruebas de humo en verde demuestran menos de lo que la gente cree. El despliegue no tiene tamaño de paso ni tiempo de observación definidos, así que todo el tráfico se mueve de golpe y la primera señal de problema es la cola de soporte. Y el disparador de vuelta atrás es una persona mirando un panel en lugar de un umbral que el pipeline pueda evaluar solo, lo que convierte un rollback rápido y aburrido en un debate. Dibujar el flujo por carriles deja a la vista qué pasos habéis automatizado y cuáles siguen dependiendo de que alguien se acuerde.

Esta plantilla es un flujo de despliegue real repartido en cinco carriles (Desarrollo, Pipeline CI/CD, QA, Responsable de releases y Operaciones) y cinco fases, de la compilación al despliegue en producción. Dibuja los tres bucles que suelen quedarse sin documentar: la puerta de calidad que devuelve una compilación fallida a desarrollo en lugar de dejarla avanzar, la verificación en preproducción que hace lo mismo antes de que nadie reserve una ventana de cambio, y el rollback automático que devuelve un despliegue con el presupuesto de error superado al mismo paso de corrección de defectos. Además presenta la estrategia de despliegue como una decisión y no como un supuesto, así que blue-green y canary aparecen en el diagrama como dos rutas con nombre que vuelven a juntarse en un desvío de tráfico con controles de salud.

Qué cubre este diagrama de flujo

En esta plantilla

• Compilación y versionado en los dos primeros carriles: desarrollo fusiona el cambio en la rama principal y el pipeline CI/CD compila el artefacto una sola vez y lo sella con el commit del que salió, para que todos los entornos posteriores desplieguen ese mismo artefacto.
• La puerta de calidad: el pipeline ejecuta las pruebas y los escaneos automáticos y QA es dueño de la decisión «¿Supera la puerta de calidad?», que encamina el fallo hacia «Corregir el defecto y recompilar» en lugar de dejarlo avanzar.
• Promoción y preproducción como pasos distintos: el artefacto se promueve al registro, el pipeline lo despliega en preproducción y QA lo verifica con pruebas de humo e integración antes de la decisión «¿Preproducción correcta?», cuya rama de fallo también vuelve a la corrección de defectos.
• Una aprobación con desenlace negativo real: el responsable de releases solicita la ventana de cambio en producción, Operaciones decide en «¿Despliegue aprobado?» y una negativa termina el intento en «Despliegue aplazado a la próxima ventana» en vez de seguir adelante en silencio.
• La estrategia de despliegue dibujada como decisión: «¿Blue-green o canary?» se divide entre desplegar en el entorno inactivo o en las instancias canary, y ambas ramas vuelven a juntarse en «Desviar tráfico con controles de salud».
• Vuelta atrás y cierre en el carril de Operaciones: la decisión «¿Presupuesto de error superado?» manda un despliegue con problemas a «Revertir a la versión anterior» y de vuelta a la corrección de defectos, mientras que uno sano completa el despliegue, lo monitoriza y cierra el registro de despliegue.

Cuándo usar esta plantilla

• Quieres documentar cómo llega de verdad una compilación a producción en un equipo cuyos pasos de despliegue viven en un fichero de configuración del pipeline y en la cabeza de dos personas
• Necesitas acordar el disparador de rollback antes de necesitarlo, para que la decisión sea un umbral medido y no un juicio bajo presión en el peor momento
• Vas a incorporar a desarrolladores, analistas de QA y personal de guardia que tienen que saber qué puerta les corresponde y qué pasa aguas abajo cuando la retienen
• Estás decidiendo servicio a servicio si despliegas blue-green o canary, y quieres dejar esa elección escrita donde la vea quien ejecuta el despliegue
• Tienes que responder a un auditor o a un cliente sobre cómo se prueba, se autoriza y se revierte un cambio, junto a vuestro procedimiento de gestión de cambios

Cómo funciona

1. Renombra los carriles con vuestros roles reales

   Sustituye Desarrollo, Pipeline CI/CD, QA, Responsable de releases y Operaciones por los roles que existen de verdad. Muchos equipos no tienen responsable de releases: en ese caso funde ese carril con quien sea dueño de producción, en lugar de dejar una banda vacía. Mantén el pipeline CI/CD como carril propio aunque sea automatización, porque el objetivo del diagrama es mostrar qué pasos ejecuta una máquina y cuáles sigue ejecutando una persona.

2. Di qué es el artefacto y dónde vive

   Escribe el tipo de artefacto (imagen de contenedor, paquete, bundle), el esquema de versionado, cómo se deriva la versión del commit, qué registro lo guarda y cuánto tiempo se conserva. Después enuncia la regla de la que depende el resto del diagrama: compilar una vez y promover el mismo artefacto, nunca recompilar por entorno. Si vuestro pipeline hoy recompila, márcalo en el diagrama, porque rompe el vínculo entre lo que se probó y lo que se publicó.

3. Define qué comprueba realmente cada puerta

   «¿Supera la puerta de calidad?» vale lo que valga su definición. Indica qué suites de pruebas tienen que estar en verde, qué tolerancia de tests inestables o de cobertura aceptáis, qué escaneos de seguridad y de dependencias bloquean la compilación y quién puede saltarse un resultado en rojo. Haz lo mismo con las pruebas de humo e integración, y enumera las diferencias conocidas entre preproducción y producción (volumen de datos, entornos de prueba de terceros, infraestructura reducida) para que todos sepan qué demuestra y qué no una ejecución sana en preproducción.

4. Fija la ventana de cambio y quién la abre

   Registra cuándo se puede desplegar, quién lo aprueba y qué pasa con un despliegue que no se aprueba. Anota si este tipo de despliegue está preautorizado como cambio estándar o necesita aprobación individual cada vez, y nombra a quién puede aprobarlo fuera del horario habitual. Si un despliegue retenido simplemente espera a la siguiente ventana, indica cuánto tiempo sigue siendo válido el artefacto antes de tener que recompilarlo y volver a probarlo.

5. Elige estrategia por servicio y escribe los pasos del despliegue

   Escoge blue-green o canary para cada servicio y refleja la elección en el diagrama. Después escribe la mecánica: los incrementos de tráfico, cuánto observas entre ellos, qué controles de salud se ejecutan en cada paso y contra qué se compara el canary. Trata los cambios de base de datos aparte, porque una migración de esquema suele ser el motivo de que un rollback no sea un simple interruptor; separar las migraciones de expansión y de contracción del despliegue de código mantiene ejecutable la versión anterior.

6. Haz medible el disparador de rollback y publica el diagrama

   Sustituye el «alguien se dará cuenta» por una señal que el pipeline pueda evaluar: tasa de error o latencia frente al objetivo de nivel de servicio, en una ventana de observación declarada y con una acción acordada. Ensaya la vuelta atrás para saber cuánto tarda. Después comparte el diagrama junto al runbook, recoge la aprobación de las personas que aparecen en él, mantén una única versión vigente y revísalo después de cualquier despliegue que saliera mal.

Preguntas frecuentes

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

El proceso de release decide qué se publica y si debe publicarse: qué cambios entran en el alcance, cuándo se congela, quién firma la aceptación de usuario y si el go/no-go es un sí. El proceso de despliegue es la mecánica que hay debajo: compilar un artefacto una vez, versionarlo, promoverlo, verificarlo en preproducción, llevarlo a la infraestructura de producción y revertirlo si se comporta mal. La relación no es de uno a uno. Una sola release puede implicar varios despliegues, y hay muchos despliegues sin release asociada, por ejemplo cuando el código sale detrás de un feature flag y se activa más tarde. Esta plantilla cubre la mecánica; si necesitas congelación de alcance, aceptación de usuario y una puerta de go/no-go, usa la plantilla de proceso de release.

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

Cinco fases cubren a casi todos los equipos. Compilación y versionado: fusionar el cambio, compilar el artefacto una vez desde una copia limpia y sellarlo con su commit. Pruebas y puerta de calidad: ejecutar las pruebas y los escaneos automáticos y devolver los fallos a desarrollo en lugar de dejarlos avanzar. Preproducción: promover el artefacto al registro, desplegarlo y ejecutar pruebas de humo e integración contra él. Aprobación y ventana: solicitar la ventana de cambio en producción y conseguir la aprobación, o aplazarlo a la siguiente. Despliegue en producción: desplegar en blue-green o canary, desviar el tráfico por pasos con controles de salud, revertir automáticamente si se supera el presupuesto de error y, si no, completar el despliegue, monitorizarlo y cerrar el registro.

¿Conviene desplegar blue-green o canary?

Blue-green mantiene dos entornos de producción y conmuta el tráfico entre ellos, así que la versión anterior sigue caliente y volver atrás es casi instantáneo. El coste es aproximadamente el doble de capacidad durante el despliegue, y todos los usuarios se mueven en el momento del cambio, de modo que un problema que solo aparece con tráfico real les llega a todos a la vez. Canary envía primero una porción pequeña de tráfico real a la versión nueva, lo que saca a la luz problemas que las pruebas sintéticas no ven, pero exige enrutado de tráfico y métricas segmentables por versión, tarda más y expone conscientemente a algunos usuarios a una versión de la que aún no te fías. Ninguna de las dos resuelve los cambios de base de datos: ambas asumen que la versión anterior sigue funcionando contra el esquema actual, y por eso las migraciones suelen partirse en pasos de expansión y de contracción que se despliegan por separado.

¿Cuándo debe revertirse un despliegue automáticamente?

Cuando una señal que el pipeline pueda evaluar por sí solo cruza un umbral acordado, no cuando alguien interpreta un panel. En la práctica eso significa tasa de error, latencia o una transacción de negocio concreta medidas frente al objetivo de nivel de servicio en una ventana de observación definida, pausando o revirtiendo el despliegue automáticamente si el consumo del presupuesto de error supera el límite acordado. Dos cosas hacen que funcione. La primera, ensayar la vuelta atrás para saber que funciona y cuánto tarda. La segunda, mantener el despliegue reversible separando los pasos irreversibles (sobre todo las migraciones de esquema y los cambios de datos de un solo sentido) del despliegue de código; si no, la automatización intentará una vuelta atrás que los datos no pueden sostener.

¿Dónde encaja la aprobación si desplegamos varias veces al día?

Aprobar cada despliegue por separado no escala, y un proceso que la gente no puede seguir se acaba esquivando. La respuesta habitual es autorizar la vía y no la instancia: definir este tipo de despliegue como cambio estándar preaprobado, con las puertas del pipeline, las pruebas y el rollback automático como control, y reservar la aprobación individual para lo que se salga de ese modelo, como las migraciones de esquema o cualquier cosa que toque un entorno restringido. Ahí es donde vive la decisión «¿Despliegue aprobado?» de este diagrama, y por eso está dibujada la rama de aplazamiento. Marcos como SOC 2 (criterio CC8.1) y el control de gestión de cambios de la ISO/IEC 27001 esperan que los cambios en producción estén autorizados, probados y documentados; no exigen una firma humana en cada despliegue. Un diagrama no es evidencia por sí mismo, pero los registros de despliegue, los resultados de pruebas y las aprobaciones que genera sí son lo que pide un evaluador.