Canary release (despliegue canario)

Un canary release envía una versión nueva primero a una parte pequeña de los usuarios, observa su comportamiento y amplía la audiencia solo si las métricas se mantienen sanas.

En un canary release, la versión nueva y la actual corren en producción al mismo tiempo. Un grupo pequeño de usuarios recibe la nueva. El equipo compara tasas de error, rendimiento y métricas de negocio entre ambos grupos. Si los números se ven bien, la proporción crece por etapas hasta que todos están en la versión nueva. Si se ven mal, el grupo pequeño vuelve a la versión actual, y la mayoría de los usuarios nunca notó nada.

El nombre viene de los canarios que llevaban los mineros para detectar a tiempo gases peligrosos.

Ejemplo

Una plataforma carga sus microfrontends desde un manifiesto. Para publicar una versión nueva del remoto de checkout, el servidor que entrega el manifiesto devuelve la URL del remoto nuevo a un porcentaje pequeño de las sesiones y la URL actual al resto. El registro de errores del frontend se etiqueta con la versión del remoto. Después de una hora sin errores nuevos se sube la proporción, y más tarde llega a todas las sesiones.

Confusión frecuente

A veces se confunde un canary con una prueba A/B. Ambos dividen el tráfico. Una prueba A/B compara dos ideas de producto para saber cuál rinde mejor. Un canary verifica que una versión nueva es segura, y termina con todos en la misma versión.

Un canary tampoco sirve sin medición. Si nadie mira las tasas de error por versión, o si el frontend no reporta errores, el release es solo un lanzamiento lento. Define de antemano qué métricas cuentan y qué umbral dispara un rollback.

Hay un detalle propio del frontend: un usuario debe quedarse en el mismo grupo durante toda la sesión, para que la página nunca mezcle chunks de dos versiones. En microfrontends se explica cómo el manifiesto lo hace posible.

Términos relacionados

• Feature flag
• Despliegue blue-green
• Rollback (reversión)