1. Feature flags: definición y propósito

Un feature flag es un mecanismo para gestionar las capacidades de una aplicación mediante interruptores lógicos embebidos en el código. En lugar de depender únicamente de nuevos despliegues, la organización controla qué funcionalidades están activas, para qué usuarios, en qué entornos y bajo qué condiciones de negocio o contexto.

En la práctica, el feature flag se convierte en un control de riesgo integrado en la aplicación: habilita lanzar funcionalidades de forma gradual, ejecutar rollbacks inmediatos y correr experimentos controlados, todo sin tener que promover un nuevo deploy. Esto habilita modelos de progressive delivery, donde el código se despliega continuamente, pero la visibilidad del cambio se gestiona con flags.

2. Implementación: abstracciones por encima de if/else

A nivel de diseño, es clave evitar una proliferación de if/else dispersos preguntando por flags en todo el código. Las buenas prácticas recomiendan encapsular la decisión detrás de abstracciones (interfaces, estrategias, factories, inyección de dependencias). El dominio debería delegar la decisión a un servicio de feature flags o a una capa de configuración, no leer variables de entorno de forma directa en todas partes.

Esto reduce el acoplamiento, facilita las pruebas y permite reemplazar el proveedor de flags (casero, LaunchDarkly, Unleash, Azure App Configuration, etc.) sin reescribir la lógica de negocio. Lo importante es que el punto de decisión esté localizado y testeado, en lugar de tener condiciones desperdigadas por controladores, servicios y vistas.

3. Flags conmutables en tiempo de ejecución y entornos distribuidos

Cuando las flags son conmutables en tiempo de ejecución, el estado debe persistir y sobrevivir a reinicios y autoscaling. Un reinicio de la aplicación no debería devolver el flag a su valor por defecto: la elección anterior debe mantenerse de forma consistente entre instancias.

En arquitecturas distribuidas, esto implica resolver escenarios de propagación en múltiples nodos de un clúster. Una práctica habitual es mantener el estado de los flags en un almacenamiento central (Consul, etcd, etc) y hacer que cada instancia lea y cachee el estado con mecanismos de polling o push. De esta forma, operaciones y negocio pueden cambiar flags en caliente sin necesidad de redeploy.

4. A/B testing y progressive delivery

Las feature flags habilitan A/B testing y pruebas multivariantes sin nuevos despliegues. El patrón típico es llevar a producción un feature apagado y exponerlo solo a un subconjunto de clientes (segmentos, beta testers, tráfico porcentual) que lo probarán de forma consciente o inconsciente.

El motor de flags decide qué variante ve cada usuario, lo que permite medir el impacto en métricas de negocio (conversión, revenue, NPS, tiempo en flujo, etc.) antes del rollout global. El mismo enfoque aplica para habilitar versiones beta de funcionalidades a grupos específicos de clientes o a usuarios internos (dogfooding).

5. Deuda técnica: riesgo y mitigación

Cada flag introduce una rama lógica adicional en el sistema. A medida que se agregan nuevos flags, crece el riesgo de que se olviden una vez que el equipo se enfoca en nuevos objetivos de negocio. El resultado es código con rutas obsoletas, condiciones complejas y pipelines más costosos de probar: la conocida deuda técnica de feature flags.

Para mitigarlo, se recomiendan políticas explícitas de revisión y limpieza:

• Definir un ciclo de vida del flag (creación, uso, decisión, limpieza).

• Documentar cada flag con propósito, owner, tipo y fecha de revisión.

• Revisar periódicamente flags que están 100% ON u OFF en todos los entornos y eliminarlos del código.

• Incorporar la limpieza de flags al backlog normal, no como "tarea opcional" del equipo técnico.

6. Modelo de clasificación obligatorio

Para gestionar la complejidad, es estándar clasificar cada flag en un modelo de tipos. La literatura (Fowler, Hodgson y otros) converge en cuatro categorías principales:

Release flags: ocultan features en desarrollo, soportan lanzamientos graduales y dark launches. Deben ser de corta vida; una vez estabilizada la funcionalidad, se elimina el flag.

Experiment flags: orientadas a A/B testing y experimentos de producto. Viven mientras dura el experimento y luego se consolidan o se descartan.

Ops flags: flags operacionales o de resiliencia (kill-switch, degradación, integraciones externas). Suelen ser de larga vida, porque son parte del control operativo.

Permission flags: exponen capacidades según permisos, plan de producto o segmento de cliente (free/pro/enterprise, región, tenant). Son flags más estables en el tiempo.

Que cada flag declare obligatoriamente su tipo permite definir expectativas claras de longevidad, gobernanza y estrategia de limpieza.

7. Naming convention y metadatos

La gestión profesional de feature flags exige una convención de nombres consistente y rica en contexto. Las guías de proveedores especializados recomiendan:

Nombres descriptivos y predecibles, por ejemplo:

rel_checkout_one_click, exp_home_banner_layout, ops_rcrc_integration_enabled, perm_corporate_reporting.

Añadir metadatos en el sistema de flags:

• Owner (equipo o squad).
• Descripción funcional.
• Tipo (release/experiment/ops/permission).
• Fecha de creación y fecha de revisión (review_for_delete).
• Tags (módulo, dominio, iniciativa, OKR).

Esto facilita auditoría, búsqueda y limpieza automática, además de habilitar reportes sobre uso de flags por dominio o producto.

{
  "key": "rel_checkout_one_click",
  "type": "release",
  "owner": "team-checkout",
  "description": "Habilita checkout simplificado",
  "createdAt": "2024-01-15",
  "reviewDate": "2024-02-15",
  "tags": ["checkout", "Q1-2024"]
}

8. Gestión centralizada y gobernanza

En lugar de manejar flags con configs dispersas por repositorios y entornos, la tendencia es utilizar un sistema central de feature flags (propio o SaaS) con SDKs para los distintos servicios.

Un servicio centralizado aporta:

Vista única de todos los flags y su estado por entorno.

Controles de acceso (quién puede cambiar qué).

Auditoría de cambios para cumplimiento y troubleshooting.

Integración con CI/CD, observabilidad y herramientas de producto/marketing.

Sobre esta base se construye la gobernanza del modelo de flags: estándares de creación, clasificación obligatoria, naming convention, políticas de expiración y criterios de limpieza. El resultado es un esquema de feature management alineado con objetivos de negocio, no solo una colección de if repartidos por el código.

Herramientas populares

SaaS: LaunchDarkly, Split.io, Flagsmith, ConfigCat

Self-hosted: Unleash, Flipper, FeatBit

Cloud providers: Azure App Configuration, AWS AppConfig, GCP Firebase Remote Config