Lanzar software solía significar una ventana de mantenimiento y dedos cruzados. Los equipos modernos utilizan estrategias que hacen que los lanzamientos sean rutinarios, y la opción implementación azul-verde versus implementación canaria es una de las primeras a las que se enfrentará. Ambos reducen el riesgo, pero lo hacen de maneras opuestas: uno prepara un reemplazo completo, mientras que el otro prueba con usuarios reales poco a poco.

Esta guía explica cómo funciona cada uno y cuánto cuesta en la práctica. Ejecutamos los pequeños ejemplos de enrutamiento de usuarios y reversión en Python 3.13, y el resultado proviene de esa ejecución. Los ejemplos de Kubernetes son ilustrativos y no los ejecutamos. Trate los porcentajes y umbrales como ejemplos iniciales para adaptarse.

La respuesta corta

Con la implementación azul-verde, ejecuta dos entornos de producción idénticos. Uno atiende a los usuarios mientras usted implementa y prueba la nueva versión en el otro, y luego cambia todo el tráfico en un solo movimiento.

Con la implementación canary, la nueva versión se ejecuta junto a la anterior. Le envía un pequeño porcentaje de tráfico real, compara los resultados y aumenta la participación paso a paso hasta que sirva a todos. El nombre proviene de los mineros canarios que alguna vez utilizaron como alerta temprana de peligro.

Azul-verde vs canario uno al lado del otro

Cómo funciona la implementación azul-verde

1. Blue está activo y atiende a todo el tráfico.
2. Implemente la nueva versión en verde, que no recibe tráfico de usuarios.
3. Realice pruebas ecológicas exhaustivas, en el entorno de producción real, mediante pruebas de humo y usuarios internos.
4. Cambie el enrutador, el equilibrador de carga o el DNS para enviar el tráfico a verde.
5. Observe de cerca, con el azul aún funcionando y listo.
6. Si algo anda mal, vuelva a cambiar. Si todo va bien, el azul se convierte en el siguiente entorno inactivo.

En Kubernetes, puedes hacer el cambio cambiando el selector de un Servicio, de modo que el tráfico se mueva a Pods etiquetados de manera diferente:

apiVersion: v1
kind: Service
metadata:
  name: shop
spec:
  selector:
    app: shop
    version: green   # was: blue
  ports:
    - port: 80
      targetPort: 8000

Fortalezas: Es conceptualmente simple, puedes probar la configuración de producción exacta antes de que los usuarios la vean y la reversión es casi instantánea. Debilidades: La infraestructura duplicada puede ser costosa, un error que pasa desapercibido en las pruebas llega a todos a la vez, y las sesiones abiertas y el trabajo en vuelo necesitan atención durante el cambio. Si utiliza DNS para el cambio, los registros almacenados en caché pueden retrasarlo. ¿Nuevo en los conceptos? Consulte nuestro tutorial de Kubernetes para principiantes.

Cómo funciona la implementación canaria

1. Implemente la nueva versión junto con la estable.
2. Dirigir una pequeña parte del tráfico, por ejemplo el 5%, hacia Canarias.
3. Compare tasas de error, latencia y métricas comerciales con la versión estable.
4. Si está sano, aumente al 25%, luego al 50% y luego al 100%.
5. Si algo se degrada, envíe todo el tráfico a la versión estable.

Muchos equipos inician un canario con personal interno, luego una región de bajo riesgo y solo después con el público en general.

Fortalezas: Una mala versión afecta solo a un grupo pequeño, y del tráfico real se aprende que ningún entorno de prueba puede reproducir completamente. Debilidades: Necesita enrutamiento basado en porcentajes y métricas por versión, las implementaciones toman más tiempo y dos versiones se ejecutan juntas por un tiempo. Un canario pequeño también puede ser demasiado silencioso para dar una señal significativa, especialmente en momentos de poco tráfico.

Enrutamiento de usuarios estable

Elegir una versión al azar en cada solicitud brinda a los usuarios una experiencia confusa, ya que pueden oscilar entre la antigua y la nueva. Una solución común es convertir una ID de usuario estable en un depósito, de modo que cada usuario siempre obtenga la misma respuesta:

import hashlib

def bucket(user_id):
    digest = hashlib.sha256(user_id.encode()).hexdigest()
    return int(digest, 16) % 100

def version_for(user_id, canary_percent):
    return "v2" if bucket(user_id) < canary_percent else "v1"

users = [f"user-{i}" for i in range(10000)]
for percent in (5, 25, 50, 100):
    share = sum(version_for(u, percent) == "v2" for u in users) / len(users)
    print(percent, round(share * 100, 1))

# 5 5.0
# 25 24.5
# 50 49.9
# 100 100.0

La proporción real siguió de cerca el objetivo. Este método tiene dos propiedades útiles más y nuestra ejecución confirmó ambas. El mismo usuario siempre recibía la misma versión. Y todos los que estaban en el grupo del 5% todavía estaban incluidos en el 25%, por lo que nadie que ya tenía la nueva versión fue movido hacia atrás a medida que crecía el lanzamiento.

En sistemas reales, una malla de servicios, un balanceador de carga o una herramienta como Argo Rollouts o Flagger generalmente maneja este enrutamiento, por lo que no es necesario que lo escriba usted mismo. Sigue siendo útil comprender lo que están haciendo.

Automatizando la decisión

Un canario sólo funciona si alguien realmente está comparando las versiones. Los controles automatizados son más confiables que una persona mirando gráficos. Aquí está la idea central, comparar la tasa de error del canary con la de la versión estable:

def should_rollback(canary_errors, canary_total, base_errors, base_total,
                    tolerance=1.5, min_requests=500):
    if canary_total < min_requests:
        return False   # not enough data to decide
    return (canary_errors / canary_total) > (base_errors / base_total) * tolerance

should_rollback(3, 100, 10, 5000)        # False: too few requests
should_rollback(30, 1000, 100, 10000)    # True:  3% against 1%
should_rollback(12, 1000, 100, 10000)    # False: 1.2% is within tolerance

Nótese el primer caso. Su tasa de error parece alta, pero con sólo 100 solicitudes, aún no es evidencia suficiente. Las herramientas reales aplican estadísticas más cuidadosas y analizan varias señales juntas:

El problema de la base de datos

El código de la aplicación se puede intercambiar en segundos, pero los datos no. Ambas estrategias suelen compartir una base de datos, por lo que durante una implementación y después de una reversión, las versiones antigua y nueva deben funcionar con el mismo esquema.

La respuesta estándar es el patrón expandir y contraer. Supongamos que desea cambiar el nombre de name a full_name:

1. Expandir: agrega la nueva columna. El código antiguo no se ve afectado.
2. Migrar: código de lanzamiento que escribe en ambas columnas y rellena las filas antiguas.
3. Switch: código de versión que se lee en la nueva columna.
4. Contrato: una vez que nada use la columna anterior, elimínela en una versión posterior.

Esto requiere varias versiones, pero cada paso se puede revertir de forma segura. Ejecutar RENAME COLUMN de una vez rompería cualquier versión que esperara el otro nombre. Tenga cuidado también con los cambios de esquema de larga duración, porque pueden contener bloqueos. Para obtener más información sobre esto, lea sobre transacciones SQL.

Rolling y otras estrategias

Una implementación de Kubernetes realiza una actualización continua de forma predeterminada, lo que se adapta a muchos servicios. Una actualización continua también cambia gradualmente, pero su participación está ligada a la cantidad de instancias y no analiza por sí sola los resultados ni se detiene ante métricas incorrectas.

¿Qué pasa con las banderas de funciones?

La implementación coloca código en los servidores y lanzamiento pone una función a disposición de los usuarios. Los indicadores de funciones los mantienen separados, al permitirle activar una función para los usuarios elegidos sin implementar nada. Funcionan muy bien con ambas estrategias: implementar con la bandera apagada y luego habilitarla gradualmente. No reemplazan estas estrategias, ya que una bandera no puede protegerlo de una versión que falla al iniciar. Recuerde eliminar las banderas antiguas, ya que se acumulan como deuda técnica.

como elegir

También se pueden combinar. Algunos equipos implementan un entorno ecológico y luego trasladan el tráfico hacia él gradualmente, obteniendo un entorno limpio y un radio de explosión limitado. Elija lo que elija, automaticelo a través de su canal de CI/CD, como explica nuestra guía de Acciones de GitHub.

Errores comunes

• Realizar cambios importantes en el esquema. La reversión no ayuda si el código anterior no puede leer los datos.
• Sin criterios de reversión. Decida qué significa “malo” antes de que comience la publicación, no durante un incidente.
• Dejar que los entornos fluyan. Si el verde difiere del azul, tus pruebas resultan menos. Defina ambos con infraestructura como código.
• Midiendo solo métricas técnicas. Una versión puede estar libre de errores y aún así interrumpir el pago.
• Nunca practiques la reversión. Ensáyalo para que funcione cuando estés bajo presión.
• Olvidar trabajos en segundo plano. Los trabajadores y las tareas programadas también necesitan un plan durante un cambio.

Conclusión

El azul verdoso te ofrece un cambio limpio y rápido. Canary te ofrece una exposición pequeña y medida. Si su monitoreo aún es básico, comience con actualizaciones continuas o azul-verde e invierta en métricas por versión antes de probar canaries. Luego, ensaye una reversión en su próxima versión, incluida la base de datos. Ese único ejercicio tiende a revelar lo que realmente necesita arreglarse.

Preguntas frecuentes

sigue aprendiendo