Definición rápida
Feature Flag (también llamado Feature Toggle) es un mecanismo de software que permite activar o desactivar funcionalidades de un producto sin necesidad de desplegar nuevo código, controlando qué usuarios ven cada feature en tiempo real.
¿Qué significa Feature Flag?
Imagina poder lanzar una nueva funcionalidad solo para el 5% de tus usuarios, medir su impacto, y luego activarla para todos (o revertirla instantáneamente si hay problemas) sin tocar código en producción. Eso es exactamente lo que hacen los Feature Flags.
Un Feature Flag es esencialmente una condición if/else en el código que determina si una funcionalidad está activa o no, pero cuyo valor puede cambiarse en tiempo real desde un panel de control, sin requerir un nuevo deployment.
El concepto es fundamental en el desarrollo moderno de software y es la base de prácticas como CI/CD, A/B Testing y «Trunk-Based Development». Empresas como Facebook, Netflix y Google los usan masivamente.
¿Cómo funcionan los Feature Flags en la práctica?
Existen varios tipos de Feature Flags según su propósito:
- Release Flags: Desacoplan el despliegue de código del lanzamiento de features. Puedes subir código nuevo a producción con el flag desactivado, y activarlo cuando estés listo.
- Experiment Flags: Para A/B testing. Segmento A ve la versión nueva, segmento B ve la versión actual.
- Ops Flags: Para control operacional. Si un servicio externo falla, puedes desactivar la feature que depende de él instantáneamente.
- Permission Flags: Para features premium. Los usuarios del plan Pro ven X; los del plan Free, no.
El flujo típico: el equipo de desarrollo sube código nuevo envuelto en un flag desactivado → QA prueba en staging → se activa gradualmente en producción (10% → 50% → 100%) → se monitorean métricas → si todo va bien, el flag se elimina y el código queda permanente.
Ejemplos reales en LATAM
Nubank (Brasil): La fintech más grande de LATAM usa feature flags extensivamente para lanzar funcionalidades de forma gradual en sus más de 90 millones de clientes. Pueden hacer rollouts por país, por tipo de cliente, o por segmento de riesgo.
Rappi (Colombia): La super-app colombiana usa feature flags para probar nuevas categorías de servicio (ej: RappiTravel, RappiCash) en ciudades específicas antes de un lanzamiento regional.
Startups SaaS chilenas: Plataformas como Buk y Cumplo usan feature flags para lanzar nuevas funcionalidades primero a sus clientes beta antes del release general.
Feature Flag vs Branch de Git
| Característica | Feature Flag | Git Branch |
|---|---|---|
| Control | Tiempo real, sin deploy | Requiere merge y deploy |
| Riesgo | Bajo (reversible al instante) | Mayor (merge conflicts) |
| Granularidad | Por usuario/segmento | Por versión completa |
| Complejidad código | Agrega deuda técnica si no se limpia | Menor si se mergea rápido |
Errores comunes con Feature Flags
- Flag debt: Acumular flags que nunca se eliminan del código. Con el tiempo, el código se vuelve ilegible. Limpiar flags obsoletos es obligatorio.
- Flags anidados: Flags dentro de flags crean una matriz de combinaciones imposible de testear.
- No tener un sistema centralizado: Gestionar flags en archivos de configuración dispersos es un anti-patrón. Usa herramientas como LaunchDarkly, Flagsmith o ConfigCat.
- Ignorar la consistencia: Un usuario debería ver siempre la misma versión durante su sesión, no alternar entre A y B.
Preguntas Frecuentes (FAQ)
¿Qué herramientas usar para Feature Flags?
Las más populares son LaunchDarkly (enterprise), Flagsmith (open source), Unleash (self-hosted), y AWS AppConfig. Para startups tempranas, incluso una tabla en base de datos puede ser suficiente.
¿Los Feature Flags afectan el rendimiento de la app?
Mínimamente si están bien implementados. Las evaluaciones se cachean y el overhead es de microsegundos. El impacto es despreciable comparado con los beneficios de control que ofrecen.
¿Cuándo NO usar Feature Flags?
Para cambios de arquitectura que afectan toda la base de código. También evita flags de larga duración (más de 3 meses) que indican que la decisión debería estar permanentemente en el código.
