Estrategias de release y rollback

Las estrategias

• Rolling: reemplaza instancias pocas a la vez. Simple y el valor por defecto en la mayoría de los orquestadores; las versiones antigua y nueva corren lado a lado por un tiempo.
• Blue/green: mantiene dos entornos completos y cambia el tráfico del antiguo (blue) al nuevo (green) de una vez. El rollback es volver a cambiar; cuesta el doble de capacidad durante el cambio.
• Canary: envía una pequeña parte del tráfico a la nueva versión, observa las métricas y luego amplía. Limita el radio de impacto de un mal release.
• Feature flags: entregan el código desactivado y lo activan por usuario, porcentaje o entorno. Separan deploy de release y dan un interruptor instantáneo de apagado.
• Shadow traffic: copia solicitudes reales a la nueva versión sin devolver sus respuestas, para comparar el comportamiento con seguridad.

El rollback es una decisión de diseño

• Mantén el artefacto anterior listo para desplegar y despliega por versión inmutable o digest.
• Haz los cambios de base de datos retrocompatibles (expand, migrate, contract) para que el código antiguo siga funcionando con el nuevo schema.
• Decide de antemano qué métrica dispara un rollback y automatízalo donde puedas.
• Practica el rollback: un rollback sin probar es una esperanza.

Ejemplo: un rollout canary

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: api
spec:
  replicas: 6
  selector:
    matchLabels: { app: api }
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: { duration: 5m }
        - setWeight: 50
        - pause: { duration: 10m }
  template:
    metadata:
      labels: { app: api }
    spec:
      containers:
        - name: api
          image: registry.example.com/api@sha256:<digest>

Elegir