¿Qué es un feature rollout?

¿Qué es un feature rollout?

Un feature rollout (despliegue gradual de una funcionalidad) consiste en lanzarla a los usuarios por etapas en lugar de a todos a la vez. Empiezas por el equipo o por una pequeña parte del tráfico, vigilas la tasa de errores, la latencia y las métricas de negocio, y amplías la audiencia solo mientras todo sigue bien. Así se separa desplegar el código de lanzar la funcionalidad: un fallo afecta al 1 % de los usuarios y no al 100 %, y la solución suele ser un interruptor, no un nuevo despliegue.

Estrategias habituales

• Despliegue por porcentaje: activas la funcionalidad para el 1 %, luego el 10 %, 25 %, 50 % y 100 % de los usuarios, con una pausa en cada paso. Suele hacerse con feature flags.
• Lanzamiento canary: una pequeña parte del tráfico va a la nueva versión, que corre junto a la anterior. Martin Fowler describe el rollback simplemente como redirigir a los usuarios de nuevo a la versión antigua. Consulta la guía de despliegue canary (en inglés).
• Despliegue por anillos: se lanza por anillos de usuarios en orden, por ejemplo el personal interno, luego los usuarios beta y después todos.
• Despliegue blue/green: dos entornos en paralelo y todo el tráfico pasa de uno a otro. No es gradual, pero ofrece una vuelta atrás rápida. Lo difícil son los cambios de esquema de la base de datos: despliégalos por separado y mantenlos compatibles con ambas versiones.
• Dark launch: el código nuevo se ejecuta en producción pero su resultado queda oculto a los usuarios, así observas la carga y el comportamiento antes de que nadie lo vea.
• Test A/B: dos variantes en paralelo para medir el efecto sobre una métrica. Responde a "cuál es mejor", no a "es seguro".

Un ejemplo paso a paso

1. Fusionas el nuevo flujo de pago detrás de un flag desactivado para todos.
2. Lo activas para tu propio equipo y observas durante un día.
3. Lo subes al 5 % de los usuarios. Comparas tasa de errores, pagos completados y tiempo de respuesta p95 entre los dos grupos.
4. Si las cifras se mantienen, pasas al 25 %, 50 % y 100 %, con una espera en cada paso acorde con lo rápido que se notarían los problemas.
5. Si los errores o la latencia se disparan en algún paso, pones el flag a 0 % e investigas.
6. Tras un periodo estable al 100 %, eliminas el flag y el código antiguo.

Errores habituales

• Sin criterios de éxito. Decide de antemano qué métricas deben mantenerse dentro de qué límites y quién las vigila.
• Avanzar por calendario. Un calendario sin monitorización solo retrasa el fallo.
• Usuarios que saltan entre lo antiguo y lo nuevo. Usa asignación persistente (sticky bucketing) para que un usuario conserve la misma variante entre sesiones.
• Un rollback que en realidad no es posible. Una migración de datos ejecutada tras el flag puede no ser reversible. Planifica primero el camino de los datos y luego el del código.
• Dejar flags olvidados. Cada flag necesita un responsable y una fecha de retirada.
• Estado desactivado sin probar. Si la ruta antigua está rota, volver atrás no te salva.

Feature rollouts, pruebas de carga y monitorización

Un rollout valida un cambio con usuarios reales, pero no debería ser la primera vez que la nueva ruta se enfrenta al volumen real de tráfico. Haz una prueba de carga de la nueva ruta antes del primer paso porcentual. LoadFocus ejecuta pruebas JMeter y k6 desde 25 regiones en la nube y el plan gratuito incluye hasta 10 usuarios virtuales. Durante el rollout, la monitorización de API sigue comprobando código de estado, cuerpo y tiempo de respuesta de forma programada (cada 5 minutos en el plan gratuito), de modo que una regresión aparece mientras revertir aún es barato. Consulta la monitorización de API de LoadFocus.

Preguntas frecuentes sobre feature rollouts

¿Qué diferencia hay entre feature rollout y feature flag?

El rollout es el proceso de lanzar por etapas. Un feature flag es una herramienta habitual para hacerlo, porque permite cambiar quién ve una funcionalidad sin desplegar código. También puedes hacer un rollout con enrutamiento canary o por anillos, sin flags.

¿Qué diferencia hay entre canary y blue/green?

Un lanzamiento canary traslada a los usuarios a la nueva versión poco a poco. Blue/green mantiene dos entornos completos y cambia todo el tráfico de una vez, con el entorno antiguo listo como rollback rápido.

¿Cuánto debe durar un rollout?

Depende del riesgo y del tráfico. Necesitas tráfico suficiente en cada paso para ver un problema, así que las funcionalidades con poco tráfico necesitan pasos más largos. Los cambios de riesgo, como pagos o migraciones de datos, merecen pasos más pequeños y esperas más largas.

¿Qué debo monitorizar durante un rollout?

La tasa de errores, los percentiles de latencia y una o dos métricas de negocio, comparando la variante nueva con la antigua y no solo el total. Las alertas deben estar configuradas antes del primer paso.

¿Toda funcionalidad debe lanzarse de forma gradual?

No. Los cambios de texto y las correcciones de bajo riesgo pueden salir directamente. Usa lanzamientos por etapas para cambios que afecten a pagos, datos, autenticación o rutas con mucho tráfico.