Cómo implementar feature flags y despliegues progresivos en tu aplicación web a medida

Subir código a producción daba miedo. El equipo preparaba la release, la empujaba al servidor y rezaba un rato. Cuando algo se torcía, el rollback se podía comer media tarde. Lo que veo hoy en los equipos con los que trabajamos es otra cosa: separar el despliegue del código de la activación de la funcionalidad. Esa separación se apoya en feature flags y despliegues progresivos, dos prácticas que bajan el riesgo, aceleran la entrega de valor y permiten decidir con datos reales de producción.

Qué son los feature flags y por qué importan

Un feature flag --también llamado feature toggle o feature switch-- es una condición en el código que decide si una funcionalidad está activa para un usuario, un grupo o un porcentaje del tráfico. En su versión más básica, es un condicional:

if (featureFlags.isEnabled('nuevo-checkout')) {
  renderNuevoCheckout();
} else {
  renderCheckoutActual();
}

Pero quedarse en el if-else es perderse lo interesante. El valor real aparece en lo organizativo y lo operativo: desacoplar despliegue y lanzamiento, hacer experimentos controlados con tráfico real, apagar funcionalidades problemáticas en segundos y dar acceso anticipado a clientes seleccionados.

Los cuatro tipos de feature flags

No todos los flags sirven para lo mismo ni viven lo mismo. Martin Fowler y Pete Hodgson propusieron una clasificación que sigue siendo la referencia.

Release flags. Permiten desplegar código incompleto en producción sin que el usuario lo vea. El equipo integra cambios en la rama principal de forma continua, ocultos tras un flag hasta que la pieza esté lista. Adiós a las ramas eternas y a los merges sangrientos. Vida útil corta: semanas o pocos meses.

Experiment flags. Para pruebas A/B o multivariantes. Un porcentaje del tráfico ve la variante A, otro la B, y son las métricas de negocio las que mandan. Vida útil de dos a seis semanas.

Ops flags. Interruptores operacionales. Si un servicio externo se cae, un ops flag desactiva la integración al instante sin tocar código. Pueden quedarse activos indefinidamente.

Permission flags. Controlan el acceso por usuario, empresa o plan de suscripción. Son la base de los modelos freemium y de los programas de early access. Vida útil larga, casi siempre permanente.

Despliegues progresivos: del todo o nada al control granular

Los feature flags son el mecanismo. Los despliegues progresivos son la estrategia que los aprovecha para reducir el riesgo de cada lanzamiento. En vez de encender una funcionalidad para el 100 % a la vez, se sube la exposición poco a poco mientras se vigilan las métricas clave.

Despliegue canary

El nombre viene de los canarios que los mineros bajaban al pozo para detectar gases tóxicos. En software, un canary dirige un porcentaje pequeño del tráfico --típicamente entre el 1 % y el 5 %-- a la nueva versión, mientras el resto sigue con la anterior. Si ese grupo dispara errores, latencia o caídas en conversión, se corta el rollout antes de que se contagie a la mayoría.

La clave está en definir antes qué métricas mandan: tasa de errores 5xx, latencia p99, conversión y excepciones no capturadas. Algunas plataformas automatizan la decisión y revierten el rollout solas cuando un umbral se supera.

Despliegue blue-green

En blue-green se mantienen dos entornos de producción idénticos. El activo (blue) sirve todo el tráfico mientras el código nuevo se despliega en el inactivo (green). Si tras redirigir el tráfico a green algo se tuerce, volver a blue es inmediato. El pero es el coste: durante un rato pagas el doble de infraestructura.

Porcentaje de rollout incremental

La estrategia más flexible mezcla feature flags con porcentajes de rollout. Empiezas con un 1 %, observas unas horas, subes al 5 %, luego al 25 %, al 50 % y por fin al 100 %. En cada escalón, el equipo comprueba que las métricas técnicas y las de negocio se mantienen dentro de lo esperado.

Este enfoque saca a la luz problemas que solo aparecen a escala. Un bug que afecta al 0,1 % de los usuarios puede no notarse con 50 personas y volverse evidente con 5 000.

Herramientas para gestionar feature flags

La elección depende del tamaño del equipo, el presupuesto y el nivel de control que necesites.

LaunchDarkly

Es la referencia del mercado enterprise. SDKs para casi todos los lenguajes, evaluación en el cliente sin latencia de red, segmentación avanzada y auditoría completa de cambios. El precio escala con el uso y no es la opción más amable para equipos pequeños.

Unleash

Alternativa open source desplegable en infraestructura propia, lo que resuelve los dolores de soberanía de datos. Trae estrategias de activación predefinidas (porcentaje, lista de usuarios, IPs) y una API REST decente.

GrowthBook

Fuerte en el cruce entre feature flags y experimentación A/B. Incluye análisis estadístico bayesiano para evaluar resultados. Es open source y la interfaz funciona tanto para desarrolladores como para gente de producto.

Solución propia

Construir el sistema en casa es viable: una tabla con definiciones de flags, caché con Redis y una interfaz de administración. La trampa habitual es subestimar la complejidad de la segmentación, la evaluación consistente entre instancias y la gestión del ciclo de vida.

El kill switch: tu botón de emergencia

Uno de los usos más rentables de los feature flags es el kill switch, un flag que apaga una funcionalidad en producción en segundos sin desplegar nada. El equivalente digital del interruptor rojo de una cadena de montaje.

Cualquier funcionalidad que dependa de un servicio externo --pasarela de pago, geolocalización, motor de recomendaciones-- debería tener su propio kill switch. Si el proveedor se cae, el switch desactiva la integración y la app sigue viva con una experiencia degradada pero funcional. Lo difícil no es la parte técnica: es decidir quién puede pulsarlo, documentar el impacto y probarlo cada cierto tiempo.

Integración con CI/CD

Los feature flags despliegan todo su potencial cuando se integran en el pipeline de CI/CD. El trunk-based development, donde todo el equipo trabaja sobre una única rama principal, depende justamente de los flags para que el código a medio cocer no llegue al usuario.

El flujo habitual: el desarrollador crea una funcionalidad protegida por un release flag, integra en la rama principal, el CI ejecuta las pruebas con el flag encendido y apagado, y la activación se controla desde la herramienta de flags, no desde el despliegue. Esta separación es importante. El CI/CD lleva el código a producción; la herramienta de flags decide quién ve qué.

Pruebas con flags

Hay un detalle que muchos equipos pasan por alto: probar la aplicación con distintas combinaciones de flags. Con diez flags activos a la vez, sobre el papel hay 1024 combinaciones posibles. Probarlas todas es inviable. Las que tienen probabilidad real en producción deberían tener cobertura.

Una opción que funciona bien es mantener dos suites de tests: una con todos los flags encendidos (el futuro del producto) y otra con la configuración actual de producción (que confirma que nada se ha roto).

La deuda técnica de los feature flags

Los feature flags resuelven problemas y crean uno nuevo: deuda técnica. Cada flag que se queda en el código después de cumplir su misión añade complejidad. Las ramas condicionales entorpecen la lectura, complican el debugging y abren la puerta a interacciones raras entre flags.

Cómo gestionar el ciclo de vida

La salida es tratar cada flag como un activo con ciclo de vida definido. Al crearlo, se registra su propósito, su propietario, la fecha de creación y la fecha esperada de retirada. Los release flags deberían desaparecer una o dos semanas después de que la funcionalidad esté al 100 %. Los experiment flags, en cuanto el experimento cierra.

Herramientas como LaunchDarkly y Unleash avisan de flags obsoletos. Si tiras de solución propia, un script semanal que detecte flags antiguos y notifique al dueño es una inversión mínima con retorno alto.

Regla práctica

La experiencia enseña que si un equipo tiene más de 20 flags activos a la vez y no sabe explicar para qué sirve cada uno, la deuda técnica ya es un problema. La limpieza de flags entra en cada sprint como tarea fija, no como algo que se aplaza eternamente.

Métricas de adopción y rendimiento

Tener feature flags sin medir su impacto es conducir con los ojos cerrados. Estas son las métricas que conviene recoger.

Tasa de exposición: Porcentaje real de usuarios que ven cada variante. Confirma que el porcentaje configurado coincide con el porcentaje real.

Métricas de negocio por variante: Conversión, tiempo en página, abandono, ingresos por usuario. Marcan si una funcionalidad se generaliza o se retira.

Métricas técnicas por variante: Latencia, tasa de errores, uso de recursos. Una funcionalidad puede ir bien en negocio y duplicar el consumo de CPU.

Tiempo medio de vida de los flags: Si crece, la deuda técnica se acumula. Estas métricas viven en dashboards de Grafana o Datadog y se revisan con regularidad.

Del despliegue binario a la entrega continua

Los feature flags y los despliegues progresivos no son solo prácticas técnicas; son un cambio de mentalidad en cómo se entrega software. Permiten lanzar con confianza, experimentar con datos reales y reaccionar en segundos cuando algo se tuerce. Si tu aplicación web a medida todavía depende de despliegues tipo "todo o nada" y quieres evolucionar hacia un modelo de entrega continua con riesgo controlado, en Tangram Consulting ayudamos a equipos a diseñar e implementar estas prácticas adaptadas a su contexto real. Hablemos sobre cómo aplicar este enfoque en tu proyecto.