Gestión de Feature Flags

Los feature flags sirven para cinco casos de uso operativos distintos, a menudo simultáneamente. (1) Lanzamiento por etapas: lanzar una característica al 5% de los usuarios el primer día, expandiéndose al 25%, 50% y 100% durante la semana siguiente. Esto convierte cada despliegue de un riesgo de todo o nada a una expansión medida y observable. (2) Pruebas A/B: dirigir a los usuarios a una de dos variantes de forma determinista (el mismo usuario siempre ve la misma variante) para una comparación estadística. (3) Programas Beta: habilitar una característica solo para las cuentas explícitamente inscritas en la beta, sin desplegar un entorno beta separado. (4) Interruptor de emergencia (Kill Switch): deshabilitar una característica problemática instantáneamente en producción sin una reversión de código, la herramienta de respuesta a incidentes más rápida disponible. (5) Puertas de características de operaciones (Ops Feature Gates): deshabilitar funcionalidades no críticas durante un incidente para reducir la carga del sistema (por ejemplo, deshabilitar consultas analíticas costosas durante una degradación del rendimiento). La disciplina de la gestión de feature flags —convenciones de nomenclatura, políticas de ciclo de vida y limpieza— es responsabilidad de Product Ops en colaboración con Ingeniería.

Las plataformas de feature flags diseñadas específicamente proporcionan capacidades críticas más allá de los simples bloques de código if/else: reglas de segmentación (habilitar para cuentas específicas, atributos de usuario o porcentaje de tráfico), integración de análisis (medición de diferencias métricas entre cohortes), controles de lanzamiento gradual y registros de auditoría. Plataformas líderes: LaunchDarkly (estándar empresarial, las capacidades de segmentación más ricas, experimentación integrada); Statsig (combina feature flags con experimentación y análisis de productos, popular en SaaS en crecimiento); Split.io (plataforma de experimentación sofisticada con profunda integración de análisis); Unleash (opción de código abierto y autoalojada para empresas con fuertes requisitos de soberanía de datos); GrowthBook (código abierto, enfocado en la experimentación). Para equipos en etapas muy tempranas, una simple tabla de flags respaldada por una base de datos y gestionada a través de un panel de administración puede ser suficiente, pero la inversión en la plataforma vale la pena cuando el equipo alcanza más de 10 flags concurrentes que requieren segmentación y análisis.

La deuda técnica de los feature flags es una de las formas más comunes y menos visibles de deuda de ingeniería. Cada flag añade una ruta de código condicional que se vuelve más difícil de entender a medida que el número de flags se multiplica: una base de código con 200 flags activos tiene teóricamente 2^200 estados posibles, lo que hace que las pruebas y la depuración sean exponencialmente complejas. La prevención requiere una política de ciclo de vida de los flags: cada flag se crea con una fecha de caducidad (la fecha objetivo en la que se eliminará); los flags que se han lanzado por completo (100% de los usuarios, sin más pruebas A/B) se marcan para su limpieza en un sprint; los flags asociados con características que fueron eliminadas se retiran inmediatamente. Product Ops mantiene el Registro de Feature Flags, un registro centralizado de todos los flags activos, su propietario, propósito, porcentaje de lanzamiento actual y fecha de caducidad. Una tarea mensual de sprint de Limpieza de Flags asegura que el registro esté actualizado y que los flags que hayan superado su fecha de caducidad se escalen para su eliminación inmediata. Los PR de 'flags muertas' que eliminan el código de los flags después de un lanzamiento completo son celebrados, ya que reducen la complejidad sin añadir nuevos errores.