Feature flags y despliegue progresivo en apps web

Cómo implementar feature flags y despliegue progresivo en tu aplicación web a medida

Tengo que confesarte algo: hace tres años desplegué un viernes a las seis de la tarde. Sí, ya sé. Teníamos presión de negocio, el sprint se cerraba ese día y yo estaba convencido de que "esta vez no pasa nada". Pues pasó. El módulo de pagos se fue al garete para el 100 % de los usuarios. El fin de semana más largo de mi carrera.

Aquel desastre me curó de espanto. Desde entonces, en nuestro equipo no se sube nada a producción sin un feature flag por delante. ¿Y sabes qué? No hemos vuelto a tener un incidente crítico en despliegue. Ni uno.

Según datos de DORA (DevOps Research and Assessment), las organizaciones que no aplican despliegue progresivo sufren hasta un 46 % más de incidentes críticos en producción. Si gestionas una aplicación web a medida --SaaS, portal corporativo o plataforma interna--, este artículo te explica cómo implementar feature flags para que los viernes por la tarde dejen de darte urticaria.

Qué son los feature flags y por qué deberían importarte

Un feature flag (también llamado feature toggle o interruptor de funcionalidad) es una condición en tu código que permite activar o desactivar una funcionalidad sin redesplegar. Como un interruptor de luz: la lámpara ya está instalada, pero tú decides cuándo encenderla y para quién.

En la práctica tiene esta pinta:

if (featureFlags.isEnabled('nuevo-panel-analitica', usuario)) {
  mostrarNuevoPanel();
} else {
  mostrarPanelActual();
}

Parece simple, ¿verdad? Pero lo que consigues es enormemente potente:

• Reducción del riesgo en cada despliegue: si algo falla, desactivas el flag en segundos. Nada de rollbacks dramáticos a las dos de la madrugada. Lo he hecho desde el móvil cenando con amigos.
• Pruebas A/B nativas: muestras la versión nueva al 10 % y mides impacto real. Datos en vez de intuición.
• Independencia entre equipos: varios desarrolladores trabajan en paralelo sin bloquearse. En un equipo de seis u ocho personas, esto es la diferencia entre entregar cada semana o cada mes.
• Control comercial: producto activa funcionalidades alineadas con campañas o fechas concretas sin tocar código.

Según LaunchDarkly (2025), las empresas que adoptan feature flags reducen un 55 % el MTTR y aumentan la frecuencia de despliegues un 40 %. Coincide con lo que he visto en nuestros proyectos.

Despliegue progresivo: el complemento imprescindible

Los feature flags son el mecanismo; el despliegue progresivo es la estrategia. El flag te da el interruptor; el despliegue progresivo define cómo y cuándo lo accionas.

Qué implica desplegar de forma progresiva

En lugar de soltar una funcionalidad al 100 % de golpe (lo que yo llamo "la ruleta rusa del deploy"), la expones gradualmente:

1. Canary release: activas para un 1-5 % del tráfico. Monitorizas errores, latencia y métricas de negocio. Si algo pinta mal, cortas sin que casi nadie se entere.
2. Expansión por segmentos: si va bien, amplías al 10 %, 25 %, 50 %... Cada paso con su período de observación.
3. Lanzamiento general: cuando los datos confirman estabilidad, activas para el 100 %.

Parece lento, pero acelera las entregas. Al reducir el riesgo, los equipos se atreven a desplegar más a menudo. Netflix hace miles de despliegues diarios porque cada uno afecta a un porcentaje controlado. Nosotros pasamos de desplegar cada dos semanas a tres o cuatro veces por semana. Con menos estrés.

Estrategias de segmentación habituales

• Porcentaje aleatorio: lo más directo. Ideal para A/B testing y validaciones de rendimiento.
• Usuarios internos primero (dogfooding): tu equipo come su propia comida antes de servirla. Lo hacemos siempre sin excepción.
• Geografía: lanzas en un mercado antes de expandir. Hemos hecho rollouts primero en Cataluña y luego en el resto para clientes del sector retail.
• Tipo de cuenta o plan: los premium ven la feature antes. "Acceso anticipado" vende.
• Identificador de usuario concreto: para betatesting con clientes seleccionados. Funciona genial en B2B donde conoces a tus clientes por nombre.

Arquitectura práctica: cómo implementarlo en tu aplicación web a medida

Basta de teoría. Voy a describir una arquitectura que funciona para apps web a medida de tamaño medio, el tipo de proyecto que manejamos la mayoría en España.

Capa 1: el servicio de feature flags

Dos caminos principales:

Opción A: solución gestionada (SaaS)

LaunchDarkly, Unleash (open source con opción cloud), Flagsmith o ConfigCat te dan panel de control, SDKs y funcionalidades avanzadas como segmentación y audit logs.

• Ventaja: implementación rápida, mantenimiento mínimo.
• Inconveniente: dependencia de tercero y coste recurrente (desde 10 EUR/mes hasta miles para enterprise).

Opción B: solución propia

Si tienes requisitos de soberanía de datos o prefieres control total:

• Una tabla en PostgreSQL/MySQL: nombre del flag, estado, porcentaje de rollout, reglas de segmentación en JSON.
• API interna con caché agresiva (Redis, TTL de 30 segundos).
• Panel de administración sencillo para que producto gestione flags sin tocar código.

Lo que hacemos nosotros: arrancamos con solución propia básica. Cubre el 80 % de las necesidades. Solo cuando la complejidad de segmentación crece de verdad migramos a SaaS. Y si lo haces, pon OpenFeature por delante para que la migración no sea un calvario.

Capa 2: integración en el código

Principios que tengo escritos en la pared de la oficina (literalmente):

• SDK centralizado: nunca accedas a flags desde cada componente. Un servicio wrapper. Si cambias de proveedor, tocas un fichero.
• Evaluación en el servidor: para decisiones críticas, evalúa en backend. La evaluación frontend es fácil de manipular con las DevTools.
• Caché local con invalidación: no hagas llamada de red cada vez que evalúas un flag. Cachea en memoria, refresca periódicamente o vía webhooks.
• Valores por defecto seguros: si el servicio de flags cae, comportamiento por defecto = desactivar la feature nueva. Esto me lo tatuaría.

Capa 3: observabilidad y métricas

Aquí es donde la mayoría de equipos la pifian. Y es lo que marca la diferencia entre un despliegue progresivo real y uno de mentira.

Monitoriza como mínimo:

• Tasa de errores segmentada por estado del flag. Si el grupo activado tiene 3 % y el otro 0,1 %, problema claro.
• Latencia de peticiones afectadas por la feature nueva.
• Métricas de negocio: conversión, tiempo en página, abandono... lo que convence a dirección.
• Alertas automáticas: si los errores del grupo activado superan un umbral, desactivación automática (circuit breaker). Esto te salva fines de semana.

Datadog, Grafana + Prometheus o Sentry bien configurado te dan esta visibilidad. Lo fundamental: que las métricas estén correlacionadas con el estado de los flags.

Errores frecuentes que debes evitar

Después de bastantes implementaciones, estos errores se repiten incluso en equipos veteranos:

1. Acumular flags sin limpiar

El pecado capital. Cada flag que dejas tras completar el rollout es deuda técnica. Regla innegociable: flag al 100 % y dos semanas estable = se elimina del código y la base de datos. Tenemos un bot que crea tickets de limpieza automáticos.

2. Flags demasiado granulares

No conviertas cada línea en un flag. He visto proyectos con 200 flags activos: ingobernable. Si tu feature incluye formulario, tabla y gráfico, normalmente un flag para los tres basta.

3. No documentar el propósito

flag_234 no le dice nada a nadie tres meses después. Usa nombres descriptivos (nuevo-panel-analitica-v2) y documenta: quién lo creó, para qué, fecha prevista de rollout y criterios de éxito.

4. Ignorar el impacto en testing

Tu suite de tests debe contemplar ambos estados de cada flag. No basta probar la feature nueva; verifica que la antigua sigue intacta con el flag desactivado. Otra razón para limpiar con disciplina.

5. Saltar la fase de observación

Pasar del 5 % al 100 % en una hora porque "todo parece ir bien" anula el propósito. He frenado a más de un product manager con ganas de correr. Tiempos mínimos: 24 horas en canario, 48 al 25 %. Hemos tenido bugs que solo aparecían con volúmenes altos a media mañana del día siguiente.

Caso práctico: plataforma de gestión para empresa de logística

Para aterrizar: empresa de logística en Madrid, plataforma web a medida para gestión de envíos, quería lanzar un nuevo algoritmo de optimización de rutas.

Enfoque clásico: dos meses de desarrollo, staging (donde todo funciona siempre), rezar y desplegar un lunes. En su lugar, feature flags:

• Semana 1: flag solo para equipo interno. Detectaron error de cálculo en rutas con más de 15 paradas. Corrección sin impacto en clientes.
• Semana 2: activación para 3 clientes pequeños. Feedback valioso sobre interfaz.
• Semana 3: rollout al 20 %. Resultado: 18 % de mejora en tiempo de entrega medio. Directo a la presentación del trimestre.
• Semana 4: rollout general al 100 %.

Resultado: cero incidentes, datos cuantitativos para justificar la inversión y un equipo con confianza para seguir iterando.

Herramientas recomendadas para el ecosistema español

Opciones que encajan en el contexto tecnológico y regulatorio de España:

• Unleash (open source): desplegable en tu infraestructura, RGPD sin discusión. SDKs para Node.js, Java, Python, .NET.
• Flagsmith (open source + cloud en UE): interfaz intuitiva, tier gratuito generoso.
• OpenFeature: estándar abierto de la CNCF que abstrae el proveedor. Ponlo siempre como capa de abstracción.
• GitLab Feature Flags: si ya usas GitLab para CI/CD, soporte nativo integrado. Cero fricción.

Cómo empezar si partes de cero

No intentes implementar todo de golpe. Un enfoque pragmático:

1. Elige una funcionalidad nueva en desarrollo. Riesgo medio, ni demasiado crítica ni trivial.
2. Implementa flags mínimo: tabla en base de datos y servicio que la consulte. Te lo montas en una tarde.
3. Despliega detrás de un flag: primero tu equipo, luego un grupo reducido de usuarios reales.
4. Mide y documenta: tiempo ahorrado en gestión de incidentes, feedback, qué mejorar. Esto convence a jefes y al resto del equipo.
5. Itera: con la experiencia del primer flag, estandariza el proceso.

En tres meses tendrás un sistema maduro y un equipo que ya no concibe los despliegues como momentos de tensión.

Conclusión: desplegar no tiene por qué ser un acto de fe

Los feature flags y el despliegue progresivo no son lujos de grandes tecnológicas. Son herramientas accesibles que cualquier empresa con una app web a medida puede y debería adoptar. Reducen riesgos, aceleran entregas y devuelven el control al equipo de producto.

La clave: empezar simple, medir desde el primer día y ser disciplinado con la limpieza de flags obsoletos. Con esos tres pilares, transformarás los despliegues de una fuente de estrés a una ventaja competitiva. Y los viernes a las seis de la tarde volverán a ser eso: viernes a las seis de la tarde.

Si necesitas ayuda para implementar feature flags en tu aplicación web a medida, contacta con nuestro equipo. Analizamos tu arquitectura y te proponemos un plan de implementación realista, alineado con tus objetivos de negocio.