En el modelo tradicional, «desplegar» significaba que el usuario recibía el código y la funcionalidad al mismo tiempo. Si algo fallaba, el rollback era la única opción. Las Feature Flags rompen este vínculo, permitiendo que el código resida en producción pero permanezca «dormido» hasta que el negocio decida despertarlo. Es la herramienta definitiva para el Dark Launching (lanzamientos ocultos) y la experimentación segura.
La Arquitectura: Microsoft.FeatureManagement
Para un desarrollador .NET, la implementación no consiste en simples condicionales if. Microsoft ha estandarizado esto mediante la librería Microsoft.FeatureManagement, que se integra profundamente con el sistema de configuración de .NET y el contenedor de inyección de dependencias.
La magia ocurre cuando conectamos nuestra aplicación a Azure App Configuration. Este servicio centraliza todas las banderas, permitiéndonos cambiarlas en milisegundos sin necesidad de reiniciar el App Service o el contenedor en AKS.
Implementación Profesional en .NET
En lugar de contaminar nuestra lógica de negocio, utilizamos Feature Flags en diferentes niveles:
- Nivel de Controlador/Acción: Usando el atributo [FeatureGate(«NuevaPasarelaPagos»)], podemos bloquear o permitir el acceso a endpoints completos de una API.
- Nivel de Servicio: Inyectamos IFeatureManager para tomar decisiones lógicas granulares dentro de nuestros procesos.
- Nivel de Vista (Front-end): En aplicaciones Blazor o ASP.NET MVC, utilizamos el Tag Helper <feature name=»OfertaNavidad»> para renderizar componentes de UI solo cuando la bandera está activa.
El Problema de la «Deuda Técnica de Banderas»
Si no se gestionan correctamente, las Feature Flags pueden convertirse en una pesadilla. El riesgo es terminar con un código lleno de «cicatrices» (banderas viejas que ya no se usan). Falla de Escenario: Imagina una aplicación con 50 banderas activas; el número de combinaciones posibles de ejecución es astronómico, lo que hace que las pruebas de regresión sean virtualmente imposibles.
La solución senior es el Ciclo de Vida de la Bandera: definir banderas temporales (para lanzamientos) y banderas permanentes (para configuraciones operativas o «Kill Switches»), con un proceso de limpieza programado tras cada lanzamiento exitoso.
Notas
- Usa Feature Filters: No te limites a On/Off. Usa filtros de Targeting para activar una función solo para el 10% de los usuarios o para aquellos con un dominio de correo específico (ideal para pruebas internas en producción).
- Caché y Rendimiento: Las banderas no deben consultarse en la red en cada petición. Configura el CacheExpirationTime en .NET para que la app mantenga los valores en memoria y se actualicen en segundo plano.
- Integración con Azure Monitor: Etiqueta tus logs de Application Insights con el estado de las banderas críticas. Si los errores suben, podrás saber instantáneamente si es culpa de la nueva función NuevaLogicaDescuento que acabas de activar.
Conclusión
Las Feature Flags son el complemento perfecto para el Canary Deployment o el A/B Testing. Nos dan el poder de realizar «lanzamientos silenciosos»: el código se despliega un martes, pero la funcionalidad se activa el viernes a las 10 a.m. sin que un solo ingeniero tenga que pulsar «Deploy».
En Azure, la combinación de App Configuration + Managed Identity ofrece un sistema de control seguro y centralizado que permite que incluso el equipo de Producto o Marketing sea quien mueva la palanca, liberando a TI de las tareas manuales de lanzamiento.
