Feature Flag: cómo funciona, tipos de flags y principios de gestión
Feature Flag es una técnica de desarrollo mediante la cual la funcionalidad de la aplicación se activa o desactiva a través de interruptores condicionales en tiempo de ejecución, sin necesidad de desplegar nuevo código. En lugar del enfoque tradicional “commit — deploy”, los feature flags permiten separar el momento del despliegue del momento de la activación de la funcionalidad. Según LaunchDarkly (2024), los equipos que usan feature flags reducen el tiempo de lanzamiento de funciones en un 40%. Los Feature flags se han convertido en un elemento esencial de CI/CD para aplicaciones móviles y web modernas.
Puntos clave
- Feature Flag — un interruptor condicional que controla la disponibilidad de funcionalidad en tiempo de ejecución
- Cuatro tipos de flags: release, experiment, ops y permission toggles con diferentes objetivos y ciclos de vida
- Gestión de flags requiere un sistema de almacenamiento, UI de configuración y monitoreo de uso
- Plataformas LaunchDarkly, Unleash y Split ofrecen SDKs para todos los lenguajes y plataformas populares
- Deuda técnica por flags no eliminados — el principal riesgo: los stale flags requieren auditoría y eliminación regulares
Qué es un Feature Flag
Feature Flag (feature toggle) es un mecanismo que permite cambiar el comportamiento de la aplicación sin modificar el código. En su forma más simple, es una construcción condicional que verifica el valor del flag antes de ejecutar nueva funcionalidad. El flag puede almacenarse en un archivo de configuración, base de datos o servicio externo y modificarse en tiempo real. Este enfoque permite a los equipos enviar código incompleto a la rama principal sin temor a que llegue a los usuarios antes de finalizar el desarrollo.
Definición y propósito
El propósito principal de los feature flags es separar el despliegue del lanzamiento. El despliegue es el proceso de colocar el código en un servidor o tienda de aplicaciones. El lanzamiento es el momento en que la funcionalidad se vuelve disponible para el usuario. Sin feature flags, estos eventos coinciden: el código sale a producción y los usuarios lo ven. Con feature flags, el código puede desplegarse en producción semanas antes del lanzamiento, activarse para pruebas internas o implementarse gradualmente para la audiencia. Esto es crítico para el trunk-based development y la entrega continua.
Ejemplo de flag simple
Considere una implementación básica de feature flag en una aplicación móvil en Kotlin. El flag se almacena en Firebase Remote Config y se carga al iniciar la aplicación. Dependiendo del valor del flag, se muestra la pantalla de perfil anterior o la nueva. Esta implementación permite lanzar una nueva versión del perfil sin publicar una actualización en App Store — solo basta cambiar el valor en la consola de Firebase.
kotlin
class ProfileFeature {
private val flags = FeatureFlagProvider()
private val profileFlag = FlagKey("new_profile_enabled")
fun getProfileScreen(): Screen {
return if (flags.isEnabled(profileFlag)) {
NewProfileScreen()
} else {
LegacyProfileScreen()
}
}
}
class FeatureFlagProvider {
fun isEnabled(key: FlagKey): Boolean {
val raw = Firebase.remoteConfig.getString(key.name)
return raw.toBoolean()
}
}Tipos de Feature Flags
No todos los feature flags son iguales. La clasificación de Martin Fowler identifica cuatro tipos de flags, que se diferencian por el propósito de uso, la duración y los requisitos de gestión. Una clasificación adecuada ayuda a elegir la infraestructura correcta y evitar problemas comunes.
Release Toggles
Los Release toggles son el tipo más común de flags. Se utilizan para ocultar funcionalidad incompleta en producción. El desarrollador envía código a la rama principal envuelto en un flag y completa gradualmente la funcionalidad. Después de finalizar y probar, el flag se activa para todos los usuarios. El ciclo de vida de dicho flag varía de unos días a dos semanas. Tras el despliegue completo, el flag se elimina del código. Los Release toggles son la base del trunk-based development.
Experiment y Ops Toggles
Los Experiment toggles funcionan junto con las pruebas A/B. No solo activan o desactivan funcionalidad, sino que dirigen al usuario a uno de los grupos experimentales. Estos flags suelen admitir reglas de segmentación complejas (por región, versión de SO, suscripción) e integración con sistemas de análisis. Los Ops toggles se utilizan para control operativo — por ejemplo, desactivar una función pesada bajo alta carga o apagar temporalmente un módulo problemático sin despliegue inmediato. Los Ops toggles deben ser lo más rápidos y confiables posible, ya que de ellos depende la estabilidad del servicio.
| Tipo | Duración | Dinámica | Propósito |
|---|---|---|---|
| Release | Días-semanas | Estático | Ocultar código incompleto |
| Experiment | Días-meses | Dinámico | Pruebas A/B y rollout |
| Ops | Horas-días | Dinámico | Control operativo |
| Permission | Meses+ | Estático | Control de acceso |
Gestión de Feature Flags
La gestión de feature flags es una disciplina separada que incluye almacenamiento, configuración, monitoreo y auditoría de flags. Sin un sistema de gestión, los flags se convierten en deuda técnica incontrolable que ralentiza el desarrollo. Veamos los aspectos clave de la gestión usando un sistema de producción como ejemplo.
Ciclo de vida del flag
Cada feature flag pasa por cuatro etapas: creación, uso, estabilización y eliminación. En la etapa de creación se definen la clave del flag, el tipo y el valor predeterminado. Durante el uso, el equipo monitorea quién activó el flag, para qué audiencia y con qué propósito. Después de la estabilización (funcionalidad completamente lista y probada), el flag debe eliminarse del código. El proceso de eliminación se automatiza mediante la revisión de código: CI verifica que todos los flags activados al 100% tengan una tarea de eliminación.
Almacenamiento centralizado
Los feature flags deben almacenarse de forma centralizada, no dispersos en archivos de configuración de cada servicio. Idealmente, un servicio dedicado con UI (LaunchDarkly, Unleash). Una opción mínimamente aceptable es un JSON de configuración en el repositorio con revisión de código para los cambios. Una base de datos para almacenar flags es menos preferible porque requiere una interfaz de gestión separada. Cada flag debe tener un propietario (equipo o desarrollador específico), una descripción y un tiempo de vida (TTL). La auditoría regular de stale flags es una práctica obligatoria, automatizada mediante una tarea de CI que verifica flags sin cambios durante más de N días.
Herramientas para Feature Flags
El mercado de herramientas de gestión de feature flags incluye tanto plataformas comerciales con ciclo de gestión completo como soluciones open-source para autodespliegue. La elección de la herramienta depende del tamaño del equipo, los requisitos de latencia y el cumplimiento normativo.
Plataformas comerciales
LaunchDarkly es el líder del mercado con SDKs para todos los lenguajes y plataformas populares (iOS, Android, Web, Backend). Admite multi-entorno, segmentación basada en reglas, experimentos A/B y eliminación automática de flags. Split es una alternativa centrada en funciones empresariales: acceso basado en roles, registros de auditoría y cumplimiento (SOC2, HIPAA). ConfigCat es una solución más ligera y asequible adecuada para equipos pequeños. Todas las plataformas ofrecen SDKs con almacenamiento en caché de valores e impacto mínimo en la latencia de la aplicación.
Soluciones open-source
Unleash es la solución open-source más popular con UI, API y SDKs para todas las plataformas principales. Admite estrategias de activación, contextos personalizados e integración con Prometheus para monitoreo. Flagsmith es una alternativa con pruebas A/B integradas y gestión de entornos. Las soluciones open-source requieren despliegue y mantenimiento de infraestructura, pero brindan control total sobre los datos y no tienen restricciones de licencia. Para aplicaciones móviles, ambas soluciones ofrecen SDKs nativos con almacenamiento en caché de valores de flags sin conexión.
Mejores prácticas
Los feature flags son una herramienta poderosa, pero sin disciplina crean deuda técnica y complican el código. Martin Fowler y los ingenieros de LaunchDarkly han formulado un conjunto de prácticas que ayudan a obtener el máximo beneficio de los feature flags sin consecuencias negativas. Revisemos las recomendaciones clave para sistemas de producción.
Evitar la deuda técnica
Cada feature flag que no se eliminó tras completar el rollout se convierte en deuda técnica. Un estudio de LaunchDarkly (2024) mostró que en promedio el 30–40% de los flags permanecen en el código después de que ya no son necesarios. Solución: implementar la regla “un flag — una tarea”. Al crear un flag, se crea una tarea de eliminación con fecha límite en el task tracker. CI verifica que no haya flags activados al 100% por más de 30 días. La revisión de código debe verificar no solo la adición sino también la eliminación de flags.
Pruebas con flags
Los feature flags crean complejidad combinatoria para las pruebas: cada flag duplica la cantidad de estados posibles de la aplicación. Para gestionar esta complejidad se utilizan pruebas matriciales que verifican todas las combinaciones de flags y pruebas de integración de alternancia de flags. Se agrega un paso al pipeline de CI que ejecuta pruebas con diferentes combinaciones de valores de flags. Para flags críticos (ops toggles), son obligatorias las pruebas de carga para verificar que el cambio de flag no cause picos de latencia ni errores.
python
class FeatureFlagService:
def __init__(self, storage):
self.storage = storage
def is_enabled(self, flag_key, user_context):
flag = self.storage.get(flag_key)
if not flag:
return False
for rule in flag["rules"]:
if self._match_rule(rule, user_context):
return rule["value"]
return flag["default"]
def _match_rule(self, rule, context):
return (
rule["percentage"] > self._hash(context.user_id)
)Preguntas frecuentes
¿En qué se diferencia un feature flag de un feature toggle?
Los términos se usan a menudo como sinónimos, pero hay un matiz: feature flag generalmente se refiere a un sistema más maduro con gestión centralizada, UI y SDKs, mientras que feature toggle es un simple interruptor binario en el código. Martin Fowler usa feature toggle como término general, pero en la industria feature flag se asocia más a menudo con plataformas comerciales (LaunchDarkly, Split).
¿Cómo afectan los feature flags al rendimiento?
El impacto en el rendimiento es mínimo con una implementación adecuada. Mejores prácticas: almacenar en caché los valores de flags en memoria con un TTL de 30–60 segundos, evitar llamadas HTTP síncronas al verificar un flag, usar SDKs con caché local y sincronización en segundo plano. Según LaunchDarkly, la latencia p99 de su SDK es inferior a 5 ms, lo cual es insignificante para la mayoría de las aplicaciones.
¿Cuándo no se deben usar feature flags?
No se recomienda usar feature flags para cambiar la lógica de negocio en operaciones financieras críticas donde es importante saber exactamente qué código se ejecuta. También se deben evitar flags para funciones de seguridad (autorización, cifrado) — desactivar dicho flag crea una vulnerabilidad. Para cambios de infraestructura (migración de base de datos, migración a nueva arquitectura), los feature flags son útiles pero requieren pruebas especialmente exhaustivas.
¿Cómo probar código con feature flags?
El enfoque principal son las pruebas matriciales: ejecutar pruebas con todas las combinaciones de flags. Para CI/CD esto puede ser demasiado costoso (2^n combinaciones), por lo que en la práctica se prueban todos los flags individualmente en ambos estados (activado/desactivado) y solo las combinaciones críticas. Las pruebas unitarias deben simular el valor del flag. Las pruebas de integración verifican escenarios específicos con valores de flags conocidos. Las pruebas E2E cubren las combinaciones más probables.
¿Cómo eliminar feature flags antiguos?
El proceso de eliminación: 1) asegurarse de que el flag esté activado al 100% para todos los usuarios y no se use en modo experimento; 2) eliminar todas las comprobaciones condicionales del flag del código, conservando solo la rama “nueva”; 3) eliminar la definición del flag del sistema de gestión; 4) actualizar las pruebas eliminando los mocks para el flag eliminado. Se recomienda automatizar este proceso mediante CI: los flags sin cambios durante más de N días se marcan como stale y requieren confirmación de eliminación.
Resumen
- Feature Flag — un interruptor condicional que separa el momento del despliegue del momento del lanzamiento de funcionalidad
- Cuatro tipos de flags (release, experiment, ops, permission) tienen diferentes propósitos, duraciones y requisitos
- Gestión de flags requiere almacenamiento centralizado, UI de configuración y auditoría regular de stale flags
- Herramientas: LaunchDarkly y Split para empresas, Unleash y Flagsmith para proyectos open-source
- Deuda técnica por flags no eliminados — el principal riesgo; las tareas de eliminación son obligatorias al crear cada flag
- Pruebas con flags requieren un enfoque matricial y simulación de valores de flags en pruebas unitarias
- Rendimiento se ve afectado mínimamente al usar caché y SDKs locales
Desarrollaremos una aplicación móvil llave en mano
IT Sectr crea aplicaciones para iOS y Android para startups y empresas desde 2017. Le asesoraremos y le propondremos la mejor solución.
Lea también