Diagrama del proceso de despliegue de software a producción

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.