Un pipeline de CI/CD transforma un cambio revisado en un artefacto verificable y una ejecución observable. Su responsabilidad incluye comprobar lo que se construye, conservar la identidad de ese artefacto y acotar cómo llega al entorno. Una ejecución verde no demuestra por sí sola que el comportamiento del producto sea correcto después del despliegue.
Blue-green mantiene una versión actual, blue, y prepara otra, green, para cambiar tráfico cuando esta última cumple sus condiciones. Ofrece una opción de volver a la aplicación anterior mientras siga siendo compatible con el estado compartido. Esa compatibilidad debe diseñarse antes del cambio.
Construir una vez y promover
La cadena comienza con revisión, pruebas y validación del cambio. Las pruebas unitarias y de integración protegen contratos distintos; las pruebas de migración y compatibilidad deben cubrir versiones que convivirán. Scans de dependencias, secretos e imágenes aportan señales que se evalúan bajo una política definida. Un scan sin hallazgos no demuestra ausencia de vulnerabilidades.
La imagen se construye y se identifica por digest. Un tag puede moverse a otros bytes; el digest permite desplegar el contenido concreto evaluado. Se promueve la misma imagen entre entornos y se vincula a su commit, resultados de pruebas y, cuando aplica, procedencia y firma verificables. La imagen de contenedor define el empaquetado; la configuración del entorno necesita su propio control.
Reconstruir una imagen después del review puede introducir dependencias diferentes aunque conserve el mismo nombre. También hay que proteger el registry y la retención del artefacto anterior durante la ventana de rollback. Una referencia inmutable no conserva un objeto que fue eliminado.
Identidad del despliegue
El job de despliegue puede usar OIDC para obtener permisos temporales, evitando guardar claves duraderas en el pipeline. La trust policy valida emisor, audience y el subject real correspondiente al repositorio o environment autorizado. El formato de GitHub puede variar; no debe suponerse que todos los repositorios usan un subject basado solo en nombres.
Cuando se usa un environment, sus reglas de protección deben restringir qué branches o tags pueden alcanzar esa identidad. La política debe limitar acciones y recursos al entorno previsto. Los pasos de build no necesitan heredar automáticamente permisos de producción. IAM y KMS explican los límites de esa identidad y el acceso a secretos.
Este YAML parcial de GitHub Actions expresa el contrato: entorno validado, grupo de concurrencia por entorno e imagen revisada por digest. id-token: write permite pedir el JWT; no concede permisos AWS. El rol y su trust policy siguen limitando la sesión. inputs.environment debe validarse contra entornos permitidos y <REVIEWED_DIGEST> sustituirse por el digest comprobado.
concurrency:
group: deploy-${{ inputs.environment }}
cancel-in-progress: false
jobs:
deploy:
environment: ${{ inputs.environment }}
runs-on: ubuntu-latest
permissions:
contents: read
id-token: write
env:
IMAGE: "registry.example.invalid/app@sha256:<REVIEWED_DIGEST>"
steps: []Se omiten deliberadamente triggers, declaración y validación de inputs, checkout, pruebas, build, verificación del artefacto, asunción del rol OIDC y despliegue con observación. steps: [] hace visible que no es un workflow ejecutable completo. La concurrencia limita jobs del mismo grupo; no garantiza orden FIFO, detención de una operación remota ni rollback.
Preparar green y cambiar tráfico
--- config: look: handDrawn --- flowchart TD change["Cambio revisado"] --> tests["Pruebas y política de seguridad"] tests --> artifact["Construir una vez<br/>Digest inmutable de imagen"] artifact --> green["Desplegar versión verde<br/>Tráfico de prueba acotado"] green --> verify["Comprobar salud, compatibilidad y objetivos de servicio"] verify --> switch["Transición de tráfico"] switch --> active["Versión verde atiende usuarios"] blue["Versión azul conservada para reversión"] --> switch active --> observe["Observar ventana del despliegue"] observe -->|"Reversión compatible"| blue blue --> shared[("Datos y colas compartidos")] active --> shared
Green debe demostrar readiness con sus dependencias, recibir pruebas apropiadas y disponer de capacidad para el tráfico previsto. Un endpoint de salud puede pasar mientras la ruta principal falla. La transición puede ser total o gradual según el servicio; los health checks, la distribución y la propagación del routing requieren observación.
AWS recomienda el blue-green nativo de ECS en la documentación actual; CodeDeploy también existe en arquitecturas que lo utilizan. Sus controllers y configuración son caminos distintos; un AppSpec de CodeDeploy no configura el controller nativo. La selección debe corresponder a las capacidades y restricciones vigentes del servicio. Esta nota describe el contrato operativo, sin añadir un workflow o ejecutar un despliegue.
Los balanceadores y el draining coordinan tráfico nuevo y peticiones en curso. Un cambio de routing no termina atómicamente conexiones existentes. Los procesos necesitan plazos de cierre y clientes capaces de resolver resultados inciertos. Una petición de escritura que sufrió timeout puede haber confirmado antes del cambio.
Datos y consumidores
Una migración expand–migrate–contract primero añade un esquema compatible, después migra datos o comportamiento y finalmente retira lo anterior cuando ya no se necesita. Antes de cambiar tráfico, blue y green deben poder leer lo que escriba cada una durante su convivencia y durante la ventana de rollback.
Añadir una columna puede ser compatible; renombrar o eliminar la única columna que blue utiliza puede impedir volver. Los defaults, constraints y cambios de semántica también importan. Volver al digest anterior no revierte escrituras ni una migración destructiva. Recuperar datos necesita un procedimiento separado y objetivos explícitos de recuperación.
Los consumidores de colas no obedecen necesariamente al switch HTTP. Si ambas versiones leen la misma cola, pueden procesar mensajes antes o después de la transición. Hay que decidir qué consumers están activos, cómo drenan, qué versiones de mensaje aceptan y cómo deduplican efectos. Duplicar procesamiento contra sistemas reales para probar green puede generar efectos repetidos; la prueba necesita aislamiento o un contrato seguro.
Rollback y fallos
El rollback requiere que blue conserve imagen, configuración, capacidad y compatibilidad. Debe indicar qué señal lo dispara, quién puede hacerlo y cuánto tiempo permanece esa opción. Blue-green también ocupa capacidad adicional; su coste durante la convivencia forma parte de la decisión.
Un pipeline cancelado no implica que un cambio remoto se haya detenido o revertido. Si la respuesta del servicio de despliegue se pierde, hay que consultar su estado antes de lanzar otro cambio. Dos releases concurrentes necesitan coordinación por entorno para evitar que una transición anterior retire recursos de la siguiente.
La verificación debe simular green saludable con errores funcionales, blue leyendo datos escritos por green, mensajes repetidos, conexiones largas y una interrupción durante el switch. Deben observarse errores, latencia, saturación, resultados de negocio y backlog, comparados con criterios establecidos antes de desplegar. El resultado es una release identificable y una respuesta comprobada al fallo, incluida la situación en que volver a blue ya no basta.