Lanzamientos canary con Actions

Imagine que lanza una función o actualización nueva. ¿Qué ocurriría si tuviera un error que afectara a todos los usuarios? Da miedo, ¿verdad?

Las versiones Canary ayudan a reducir este riesgo al distribuir los cambios gradualmente, primero a un pequeño subconjunto de usuarios. Es como enviar un «canario a una mina de carbón» para comprobar el aire antes de que entren los demás.

Las versiones Canary ofrecen varias ventajas importantes:

• Menor riesgo: Limite el impacto de los problemas a un grupo pequeño de usuarios.
• Comentarios del mundo real: Obtenga datos de producción sobre el rendimiento y la estabilidad.
• Reversión rápida: Si surgen problemas, revierta rápidamente solo el pequeño grupo Canary o todo el servicio.
• Exposición controlada: Aumente gradualmente la exposición de los usuarios a medida que aumenta la confianza.

Es posible que recuerde las implementaciones Blue/Green, en las que el tráfico cambia instantáneamente entre dos entornos idénticos.

Las versiones Canary son diferentes. En lugar de un cambio instantáneo, implican un cambio gradual del tráfico. La nueva versión se ejecuta junto a la anterior y, al principio, solo un pequeño porcentaje de los usuarios ve la nueva versión. Esto permite realizar una supervisión detallada antes de completar la implementación.

Este es el flujo básico de una versión Canary:

1. Implementar la nueva versión: Se implementa una nueva versión de la aplicación en un pequeño conjunto de servidores o instancias, junto con la versión estable existente.
2. Dirigir una pequeña parte del tráfico: Se configura un balanceador de carga o una malla de servicios para enviar un pequeño porcentaje (por ejemplo, del 5 al 10 %) del tráfico de usuarios a la nueva versión.
3. Supervisar: Se supervisan atentamente el rendimiento, las tasas de error y los comentarios de los usuarios del grupo Canary.
4. Promover o revertir: Si todo parece correcto, el tráfico aumenta gradualmente o la nueva versión se promueve al 100 %. Si se producen problemas, se revierte Canary y el tráfico vuelve a dirigirse a la versión estable.

GitHub Actions puede orquestar todo el proceso de lanzamiento canario. No gestiona directamente el tráfico (esa es responsabilidad de su infraestructura), pero activa los pasos:

• Compilar y probar su aplicación.
• Implementar la nueva versión en un entorno canario.
• Iniciar los cambios de tráfico mediante llamadas a la API de su balanceador de carga o malla de servicios.
• Esperar los resultados de la monitorización o las aprobaciones manuales.
• Promover el canario o activar una reversión.

Un flujo de trabajo típico de GitHub Actions para un lanzamiento canario podría ser similar al siguiente:

name: Canary Deployment

on: push

jobs:
  build:
    # ... build and test steps ...

  deploy-canary:
    needs: build
    steps:
      - name: Deploy to Canary Group
        # ... call script/tool to deploy and shift 10% traffic ...

  monitor-canary:
    needs: deploy-canary
    # ... wait for monitoring/approval ...

  promote-or-rollback:
    needs: monitor-canary
    # ... conditionally promote to 100% or rollback ...

Cada paso interactuaría con sus herramientas de implementación.

Aunque GitHub Actions se encarga de la orquestación, las decisiones reales y los comandos de implementación suelen ejecutarse dentro de scripts. Este es un ejemplo en Python que simula la lógica de un despliegue canario. Imagine una Action que ejecuta este script:

Una monitorización eficaz es fundamental. Su flujo de trabajo de GitHub Actions puede integrarse con sistemas de monitorización de varias formas:

• Llamadas a la API: Consultar herramientas de monitorización (por ejemplo, Datadog o Prometheus) para obtener métricas clave.
• Comprobaciones de estado: Consultar periódicamente los endpoints de estado de la aplicación.
• Puertas manuales: Pausar el flujo de trabajo para que una persona lo revise y apruebe.
• Esperas basadas en el tiempo: Esperar un periodo establecido para que las métricas se estabilicen.

A continuación, el flujo de trabajo utiliza estas señales para decidir si promocionar o revertir el despliegue.

Tras la fase de monitorización, GitHub Actions utiliza lógica condicional para decidir el siguiente paso. Puede utilizar sentencias if en las definiciones de sus trabajos o pasos.

  promote-or-rollback:
    needs: monitor-canary
    if: success() && needs.monitor-canary.outputs.canary_ok == 'true'
    steps:
      - name: Promote Full Rollout
        # ... command to shift 100% traffic to new version ...

  rollback:
    needs: monitor-canary
    if: failure() || needs.monitor-canary.outputs.canary_ok == 'false'
    steps:
      - name: Rollback to Stable
        # ... command to shift 100% traffic to old version ...

Esto garantiza una reacción automática al rendimiento del canario.

Ha aprendido sobre las ventajas y el funcionamiento de los lanzamientos canarios. Compruebe sus conocimientos.

En esta lección, ha aprendido sobre los lanzamientos canarios, una potente estrategia de implementación para distribuir gradualmente nuevas versiones de software a un subconjunto de usuarios.

• Los lanzamientos canarios minimizan el riesgo y proporcionan información del mundo real.
• GitHub Actions orquesta la compilación, la implementación en el entorno canario, la monitorización y los pasos de promoción o reversión condicionales.
• Una monitorización eficaz y la lógica condicional son fundamentales para que los pipelines canarios tengan éxito.

Al utilizar canarios, puede implementar con mayor confianza y control.