Despliegue Blue-Green
Dos entornos de producción completos, con el tráfico alternado de uno a otro — lo que permite una reversión instantánea y total si el nuevo entorno se comporta mal.
Despliegue y habilitación · Paso 05 · Cómo trabajamos
El lanzamiento es una decisión, no un evento.
Desarrollo e Integración produce software verificado —pero el software verificado aún no es software en producción. Esta etapa regula cómo, cuándo y con qué seguridad ese software se expone al tráfico real de producción, y garantiza que las personas responsables de operarlo estén preparadas antes de que llegue.
En OpenQCore, el despliegue se trata como una exposición controlada al riesgo, no como un único momento irreversible. Una versión no está "terminada" cuando el código llega a producción. Lo está cuando se ha expuesto gradualmente, observado en condiciones reales y confirmado como segura — con un camino definido de retroceso si no lo fuera.
No esta pregunta
"¿El código está listo para desplegarse?"
En su lugar, esta pregunta
"¿Cómo exponemos este cambio a usuarios reales de manera que limite el radio de impacto de cualquier cosa que no anticipamos — y podemos revertirlo rápidamente si es necesario?"
Entrega progresiva · Contención del riesgo · Reversibilidad · Preparación · Habilitación
Por qué el despliegue sigue a la verificación
Verificado no es lo mismo que probado en producción.
La etapa anterior confirma que un cambio cumple sus criterios de aceptación en pruebas. No confirma cómo se comporta ese cambio bajo la carga real de producción, el comportamiento real de los usuarios o las interacciones reales con sistemas que no pueden replicarse completamente en un entorno de prueba. Despliegue y Habilitación existen precisamente porque esa brecha es real — y porque cerrarla de manera segura requiere su propia disciplina.
Listo para el despliegue → Exposición controlada en producción
Por qué importa la disciplina de despliegue
La velocidad sin reversibilidad no es progreso.
La misma investigación DORA presentada durante Desarrollo e Integración — Accelerate (2018), de Forsgren, Humble y Kim — combina sus métricas de rendimiento con dos métricas de estabilidad que importan específicamente en esta etapa.
Frecuencia de despliegue
Con qué frecuencia una organización publica con éxito en producción.
Forsgren, Humble & Kim, Accelerate (2018); DORA, investigación State of DevOps.
Tiempo para restaurar el servicio
Cuánto tiempo se tarda en recuperarse cuando un despliegue degrada la producción.
Forsgren, Humble & Kim, Accelerate (2018); DORA, investigación State of DevOps.
Las organizaciones de alto rendimiento, según esta investigación, no se limitan a desplegar con frecuencia: despliegan de forma que el tiempo de recuperación sea corto cuando algo sale mal. OpenQCore trata esto como un objetivo único, no como una compensación: las prácticas en esta etapa están diseñadas para que el despliegue sea tanto frecuente como rápidamente reversible.
Estrategias de entrega progresiva
Separar la decisión de lanzar de la decisión de desplegar.
Las prácticas formalizadas en el influyente Continuous Delivery (2010) de Humble y Farley distinguen entre desplegar un cambio y liberarlo a los usuarios — una distinción que OpenQCore considera una elección de diseño fundamental para cómo el software llega a producción.
Lanzamientos canary
Una nueva versión se expone primero a una pequeña fracción del tráfico real, se observa según señales definidas y solo se amplía una vez que esas señales se mantienen.
Feature Flags
El código puede desplegarse en producción permaneciendo inactivo para los usuarios — separando el acto de enviar el código del acto de exponer una funcionalidad.
Entornos de despliegue y promoción
Un cambio se gana su camino hacia producción. No se envía allí directamente.
Un cambio se mueve a través de entornos definidos — desarrollo, preproducción y producción — con verificación explícita en cada promoción, no una sola pasada de pruebas seguida de un lanzamiento directo.
Desarrollo
Donde se construye un cambio y se verifica inicialmente en aislamiento.
Preproducción
Donde un cambio se verifica frente a condiciones, configuraciones e integraciones similares a las de producción.
Producción
Donde un cambio se expone a tráfico real — de forma progresiva y bajo observación.
Diseño de reversión y recuperación
El plan de reversión se redacta antes del despliegue, no durante el incidente.
Una estrategia de reversión decidida cuando el sistema ya está degradado es una estrategia tomada bajo presión, con información incompleta y, con frecuencia, demasiado tarde. OpenQCore define la ruta de reversión para un cambio antes de que se despliegue —no después de que algo salga mal.
Condiciones definidas para activar la reversión
Las señales específicas que provocarían una reversión, acordadas de antemano en lugar de juzgadas en el momento.
Compatibilidad de datos y estado
Consideración explícita sobre si una reversión es segura dadas las modificaciones en datos o esquemas que introdujo el despliegue.
Objetivo de tiempo de recuperación
Un objetivo declarado sobre la rapidez con la que el servicio debe ser restaurado si se requiere una reversión.
Infraestructura como Código y Reproducibilidad
Un despliegue que no puede repetirse exactamente no puede ser confiable.
Los pasos de despliegue se definen como código — versionado, revisado y ejecutado de forma idéntica cada vez — en lugar de realizarse como acciones manuales dependientes de la memoria de una persona sobre la secuencia correcta. Esta es una práctica fundamental dentro del mismo corpus de investigación sobre entrega continua mencionado arriba: un proceso de despliegue que no puede reproducirse exactamente no puede verificarse y no puede automatizarse de forma segura.
Evaluación del riesgo del despliegue
Cada despliegue se evalúa antes de que ocurra, no después.
Consistente con el modelado de amenazas introducido durante Desarrollo e Integración, cada despliegue se evalúa según su perfil de riesgo específico antes de proceder.
Radio de impacto
Cuántos usuarios, sistemas o flujos de trabajo se verían afectados si este cambio específico se comporta de forma inesperada.
Reversibilidad
Qué tan rápida y limpiamente puede revertirse este cambio específico si es necesario.
Exposición de dependencias
Qué sistemas o equipos aguas abajo se ven afectados por este despliegue y si han sido informados.
La canalización de despliegue progresivo
La exposición solo aumenta cuando la evidencia lo respalda.
Canary (pequeño porcentaje) → Monitorizar señales definidas → Ampliar exposición → Monitorizar señales definidas → Despliegue completo. En cualquier punto de esta secuencia, una reversión es un resultado diseñado — no una improvisación de emergencia. La expansión a la siguiente etapa es una decisión tomada en base a la evidencia recogida en la etapa actual, no un valor predeterminado que ocurre automáticamente con el tiempo.
Este enfoque refleja el concepto de presupuesto de errores (error budget), descrito en Site Reliability Engineering de Google (2016): una cantidad definida y aceptable de inestabilidad que se permite al sistema 'gastar', utilizada para convertir la compensación entre la velocidad de lanzamiento y la fiabilidad en una decisión explícita y medida en lugar de implícita.
Habilitación: Documentación y preparación del equipo
Un sistema que nadie puede operar no ha sido realmente desplegado.
El despliegue se considera con frecuencia completado una vez que el software está en producción. OpenQCore lo considera completado solo cuando las personas responsables de operar, dar soporte y solucionar problemas de ese software estén realmente preparadas para hacerlo.
Runbooks operativos
Procedimientos documentados para tareas operativas comunes, modos de fallo conocidos y cómo responder a ellos.
Preparación para guardias
Confirmación de que las personas responsables de responder a incidentes tienen el acceso, el contexto y las vías de escalado que necesitan.
Transferencia de conocimiento
Entrega explícita del conocimiento operativo al equipo u organización que se encargará del sistema en adelante.
La puerta de decisión de despliegue
Un despliegue procede porque la evidencia lo respalda — no porque esté programado.
Todo despliegue planificado alcanza una puerta de decisión definida antes de proceder.
Despliegue
La evaluación de riesgos, el plan de reversión y la preparación están satisfechos — el despliegue procede.
Retraso
Un riesgo identificado aún no ha sido mitigado suficientemente — el despliegue espera hasta que lo sea.
Reversión
Un cambio desplegado ha activado una condición definida de reversión — se restaura el estado anterior.
Escalar incidente
Un despliegue ha causado un impacto que requiere una respuesta formal de incidentes más allá de una reversión estándar.
Una puerta de despliegue que nunca retrasa ni revierte no está evaluando el riesgo — simplemente está registrando la programación.
Lo que produce esta etapa
Un sistema en funcionamiento, y la capacidad de operarlo.
Dependiendo del alcance del compromiso, esta etapa produce:
Runbook de despliegue
El procedimiento específico y repetible usado para desplegar este cambio y cambios futuros similares.
Plan de reversión
Las condiciones de activación definidas, el procedimiento y el objetivo de tiempo de recuperación para revertir este despliegue.
Registro de promoción del entorno
Documentación de cómo el cambio pasó por desarrollo, preproducción y producción, y qué se verificó en cada etapa.
Documento de evaluación de riesgos
El radio de impacto, la reversibilidad y la exposición de dependencias evaluados antes del despliegue.
Materiales de capacitación del equipo
Runbooks, confirmación de preparación on-call y transferencia de conocimientos completada antes de la entrega.
Informe de despliegue progresivo
Las señales observadas en cada etapa de exposición y la evidencia que respalda la expansión al despliegue completo.
De Despliegue a Monitoreo y Optimización
Que esté en producción no significa que esté comprendido.
Despliegue y habilitación producen un sistema que funciona de forma segura en producción, con las personas responsables preparadas para operarlo. Aún no generan una comprensión continua de cómo se comporta ese sistema a lo largo del tiempo, ni un mecanismo estructurado para mejorarlo. Ese es el propósito de la siguiente y última etapa de esta metodología.
Exposición controlada en producción → Preparación operativa → Monitoreo y Optimización
Paso 06
Monitoreo y Optimización
Entender cómo se comporta realmente un sistema en producción y mejorarlo de forma continua basándose en evidencia real.
Referencias de investigación y metodológicas
Forsgren, N., Humble, J., & Kim, G. — Accelerate: The Science of Lean Software and DevOps (2018); Google Cloud, DORA State of DevOps research
Fuente de las métricas de frecuencia de despliegue y tiempo de recuperación mencionadas arriba.
Humble, J. & Farley, D. — Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (2010)
Fuente de la distinción deploy/release, el despliegue blue-green y los principios de infraestructura como código mencionados arriba.
Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (eds.) — Site Reliability Engineering: How Google Runs Production Systems (2016)
Fuente del concepto de presupuesto de error mencionado en la sección de despliegue progresivo anterior.