Despliegue canario: libera primero a pocos usuarios

Un despliegue canario libera una nueva versión de tu software a una pequeña porción del tráfico real, mientras todos los demás siguen en la versión actual. Si el canario se comporta bien, amplías la porción paso a paso. Si no, devuelves el tráfico y solo unos pocos usuarios se vieron afectados.

El nombre viene del canario en la mina de carbón: una pequeña alerta temprana de que algo anda mal antes de que todo el grupo quede expuesto. Lo uso sobre todo cuando cambio un sistema del que personas reales dependen todos los días, porque convierte un release riesgoso en una serie de releases pequeños y reversibles.

¿Qué es un despliegue canario?

En un release normal, todos los usuarios pasan a la nueva versión en el mismo momento. Si hay un bug, todos se lo encuentran. En un release canario, dos versiones corren en paralelo: la estable y el canario. Un enrutador, un load balancer o un switch a nivel de aplicación decide qué solicitudes van a cada una.

Empiezas con una porción pequeña, observas y la aumentas por etapas. En cada etapa te haces una pregunta: ¿el canario está al menos tan sano como la versión estable? La comparación es lo que importa. Una tasa de error aislada dice poco, pero una tasa de error más alta en el canario que en la versión estable te dice algo concreto.

¿En qué se diferencia del blue-green y de los feature flags?

El despliegue blue-green mantiene dos entornos completos y pasa todo el tráfico de uno al otro de una sola vez. Un canario mueve el tráfico de forma gradual. Los feature flags controlan el comportamiento dentro del código, a menudo por usuario, y se usan con frecuencia para implementar un canario. Se superponen, y muchos equipos los combinan: despliegan el código apagado y luego lo exponen a un grupo cada vez mayor.

¿Cómo eliges qué usuarios o qué tráfico van al canario?

Esta es la decisión que hace que el enfoque funcione o fracase. Un canario que solo recibe tráfico que a nadie le importa no demuestra nada. Un canario que atiende primero a tu cliente más grande es una imprudencia.

Una secuencia que me ha funcionado:

1. Usuarios internos y personal. Encuentran los problemas obvios y los van a perdonar.
2. Una pequeña muestra aleatoria del tráfico. El muestreo aleatorio da una comparación justa con la versión estable.
3. Segmentos de bajo riesgo. Por ejemplo, cuentas gratuitas, una región o un tenant que aceptó entrar antes.
4. Grupos más amplios, por etapas, dejando a los clientes de mayor valor para el final.

¿Asignación aleatoria o fija?

Haz que la asignación sea fija. Si un usuario salta entre versiones en cada solicitud, puede ver pantallas inconsistentes, perder la sesión o toparse con datos escritos en un formato que la otra versión no puede leer. Asigna por ID de usuario, ID de cuenta o una cookie, para que la misma persona se quede en la misma versión durante la prueba.

Cuidado con los flujos de dinero y de datos

Todo lo que cobra tarjetas, envía emails o escribe datos que la versión anterior también debe leer merece precaución extra. Como trabajé en el equipo de carrito y checkout de Total Wine & More, trato el flujo de dinero como el último lugar para arriesgarse. Mantén el canario pequeño por más tiempo en esos flujos y comprueba que ambas versiones puedan convivir con los datos que escribe la otra. Un canario no puede deshacer un registro corrupto, así que la compatibilidad de datos tiene que estar resuelta antes de mover el tráfico.

¿Qué métricas te dicen que el canario está sano?

Elige las métricas y los umbrales antes de empezar. Si decides qué cuenta como sano mientras miras un dashboard bajo presión, vas a racionalizar. Compara el canario con la versión estable en la misma ventana de tiempo.

Las métricas de negocio son las que la gente omite

Un release puede pasar todas las verificaciones técnicas y aun así impedir en silencio que la gente termine una compra o una postulación. Los dashboards de servidor no van a mostrar eso. Si el producto tiene una acción principal, mide su tasa de éxito en ambas versiones. En una migración, esta suele ser la señal de salud más honesta que tienes.

Ojo con el tamaño de la muestra

Con un canario muy pequeño, un puñado de solicitudes puede mover mucho un porcentaje. No promuevas porque los primeros diez minutos se vieron limpios. Deja que el canario corra el tiempo suficiente, y con tráfico lo bastante variado, para que la comparación signifique algo. Cuánto tiempo depende de tu volumen, así que trata cualquier duración específica como algo que debes ajustar para tu sistema.

¿Cuándo promover o revertir un canario?

Escribo las reglas como un checklist corto antes del release. Una versión simple:

• Promueve cuando el canario se mantenga dentro del margen acordado respecto de la versión estable en errores, latencia y la métrica de negocio durante toda la ventana de observación.
• Espera cuando los resultados sean ambiguos. Quédate en el porcentaje actual y reúne más datos en lugar de avanzar.
• Haz rollback cuando se cruce cualquier límite estricto, como un aumento claro de errores, una caída en la acción principal del negocio o cualquier señal de datos escritos incorrectamente.

El rollback debería ser aburrido. Lo ideal es que signifique cambiar un peso de enrutamiento o apagar un flag, no volver a desplegar bajo estrés. Prueba ese camino antes de necesitarlo. Si revertir requiere un procedimiento manual largo, tu canario te protege menos de lo que crees.

La promoción y el rollback automatizados son posibles, y algunas herramientas lo hacen con base en umbrales de métricas. Aun así, yo correría los primeros releases con una persona vigilando, para que los umbrales se ajusten a la realidad antes de confiar en que actúen solos.

¿Cómo reducen los releases canario el riesgo en una migración?

Migrar una plataforma en producción es donde más rinden los canarios. Cuando lideré la migración de una plataforma que postula automáticamente a ofertas de empleo por sus usuarios, toda la arquitectura pasó de un stack legado a uno nuevo mientras la gente seguía usándola todos los días. Un cambio único habría significado apostarlo todo a un solo momento. Avanzar de forma gradual significó que cada pieza podía demostrarse primero con tráfico real.

El patrón es sencillo:

1. Pon un switch delante de todo antes de escribir código nuevo, para controlar qué versión atiende cada solicitud. Este es siempre mi primer paso.
2. Mueve una pequeña parte de la funcionalidad al nuevo stack.
3. Envía una pequeña porción del tráfico a esa parte como canario y compara.
4. Amplía la porción y luego retira la pieza antigua cuando la nueva haya demostrado lo que vale.

Por eso prefiero la migración incremental a una reescritura big-bang. Una reescritura suele costar más y tardar más, en parte porque el sistema antiguo tiene que seguir funcionando en paralelo de todos modos. Un canario hace útil ese período en paralelo: aprendes del comportamiento real en lugar de esperar al día del lanzamiento para descubrirlo.

Un límite a tener en cuenta: un canario te dice cómo se comporta la nueva versión con el tráfico que recibe. No va a detectar un caso límite raro que ninguna parte de ese tráfico haya activado, así que complementa las pruebas y el code review en lugar de reemplazarlos. Para sistemas más antiguos, consulta cómo cambiar código antiguo de forma segura.

¿Necesitas infraestructura especial para los despliegues canario?

No. Las herramientas especializadas lo facilitan a escala, pero la idea funciona con configuraciones modestas. Opciones, de la más simple a la más elaborada:

• Feature flags en la aplicación. Expón la nueva ruta de código a un porcentaje o a una lista de usuarios. No requiere cambios de enrutamiento.
• Enrutamiento ponderado en un load balancer o proxy inverso. Muchos de los más comunes permiten enviar un porcentaje de las solicitudes a un segundo grupo de servidores.
• División de tráfico a nivel de plataforma. Las plataformas de orquestación de contenedores y de nube suelen ofrecer rollouts ponderados, y algunas plataformas de hosting ofrecen división de tráfico. Revisa la documentación actual de tu proveedor para saber qué está soportado.
• Herramientas dedicadas de entrega progresiva que automatizan el análisis y el rollback.

Lo que sí necesitas, sea cual sea la herramienta, es observabilidad. Si no puedes ver errores, latencia y una métrica de negocio separados por versión, no estás corriendo un canario, solo estás liberando despacio. Etiquetar logs y métricas con la versión es lo primero que configuro; el enrutamiento puede ser rudimentario.

También tienes que manejar el estado compartido. Ambas versiones van a acceder a la misma base de datos, así que los cambios de esquema deben ser retrocompatibles mientras las dos coexisten. Agrega columnas antes de usarlas y elimina las antiguas solo cuando la versión anterior ya no esté.

¿Planificas un canario para tu propio release?

Si estás evaluando cómo liberar una migración o un release riesgoso, escribe a me@filipeeduardo.dev con una breve descripción de tu configuración. Con gusto le echo un vistazo y te digo qué revisaría primero.