Está bien codificar los feature flags a mano
It's OK to hardcode feature flags (2025)
Los feature flags son esenciales para controlar el lanzamiento de nuevas funciones, pero el software de gestión de flags añade complejidad y riesgo innecesarios. Este artículo defiende el enfoque más simple: codificarlos directamente en el código o en un archivo JSON leído al inicio. Argumenta que los flags hardcodeados son fiables, seguros y fáciles de mantener, y que la mayoría de los equipos no necesitan cambiar flags en tiempo de ejecución a escala. Solo cuando esa necesidad real surge, merece la pena considerar una solución más sofisticada.
Son la forma más aburrida de hacerlo, y por eso son la mejor forma de hacerlo.
- jameshart
En mi experiencia, estos (los feature flags basados en configuración y los servicios de feature flags) son en realidad dos capacidades complementarias que resuelven dos problemas completamente diferentes pero que casualmente comparten el mismo nombre: feature flags.
El enfoque de configuración es fundamental para usar los feature flags como herramienta del ciclo de vida del desarrollo de software. Así es como gestionas tener un código base que contiene el código inacabado de la nueva característica x, pero que aún así puede desplegarse y pasar todas las pruebas sin que la característica x esté activada.
En este modelo, necesitas un mecanismo que permita a un desarrollador que trabaja en la característica x activarla para pruebas locales, y que tu sistema de CI pueda interactuar con el sistema de flags para probar que la aplicación funciona en ambos estados: con x activada y desactivada.
Esto es ideal para modelos de desarrollo basados en tronco; las ramas de características son un enfoque alternativo que realmente no se beneficia de esto (de hecho, añade complejidad al trabajar en ramas de características).
Mientras tanto, los servicios de feature flags sirven para resolver el problema de que diferentes personas que usan el mismo software necesitan diferentes características activadas. Esto puede ser tan simple como testers internos o usuarios beta, puede ser mantener características para lanzarlas en ventanas de actualización fijas por cliente, o puede ser parte de una estrategia de gestión de riesgos donde las características se despliegan mediante exposición progresiva.
También puede ser tentador mezclar tu sistema de feature flags con un sistema de pruebas A/B: puedes usar un servicio de feature flags para exponer una característica a una cohorte de prueba y […]
- jdwyah
Estoy en mi segunda startup de feature flags, pero también estoy algo de acuerdo con esto.
Cada proyecto debería tener flags, pero muchos proyectos solo necesitan lo básico y un servicio es excesivo.
Aun así, crear tu propio JSON me sigue pareciendo algo que deberíamos evitar. Sí, al principio es 95% booleano. Pero luego quieres un rollout. Y luego quieres algunas reglas de segmentación. Y luego quieres no booleanos… quizás algo de JSON. ¿No sería genial que el JSON pudiera ajustarse a un esquema…? Y eventualmente piensas: maldición, realmente quiero cambiar esto sin desplegar. O quieres leer el mismo flag desde múltiples servicios.
He intentado incorporar este mínimo común denominador en https://quonfig.com. Úsalo totalmente gratis y de código abierto como SDK, y es simplemente cargar JSON que puedes rastrear en git. A los agentes les encanta, recarga en caliente, SDK en muchos lenguajes. Pero en comparación con hacerlo tú mismo, tienes mucho margen en el diseño. Un montón de operadores de segmentación. Segmentos, etc. Y luego, si realmente quieres una buena interfaz de usuario / red de entrega para actualizaciones en tiempo real, puedes usar la parte de pago.
Descripción de uso local: https://docs.quonfig.com/docs/how-tos/open-source-local
- avlcodemonkey
Si trabajas con C#, Microsoft añadió soporte de primera clase para la gestión de características en .Net con https://github.com/microsoft/featuremanagement-dotnet. Proporciona la lógica para activar/desactivar simple, segmentación de usuarios, despliegues porcentuales y horarios. Usar la gestión de características junto con flags hardcodeados en `appSettings.json` tiene mucho sentido para una aplicación más simple.
Cuando tu arquitectura crece y empiezas a necesitar sincronizar configuración entre múltiples aplicaciones, o tener usuarios no técnicos que cambien flags, entonces probablemente has superado el hardcodeo y necesitas considerar construir (o comprar) un servicio. Probablemente no quieras que los dueños de producto intenten establecer una variable de entorno como `FeatureManagement__NewFeature__EnabledFor__0__Name`. Azure App Configuration es la opción a seguir si estás dispuesto a usar Azure: proporciona una interfaz agradable para editar flags en lugar de lidiar con JSON. O bien, he estado construyendo https://featureflags.app/ como proveedor alternativo si prefieres mantenerte alejado de Azure. Es una especie de punto intermedio entre el hardcodeo y una plataforma completa como LaunchDarkly.
- maxidog
Actualmente estoy haciendo ingeniería inversa de una gran aplicación empresarial y la hinchazón de feature flags es realmente asombrosa. En mi opinión, la complejidad excesiva de los feature flags es un síntoma de una gerencia indecisa y en la que los desarrolladores no confían.
- stronglikedan
A menos que seas Knight Capital, por supuesto. https://www.youtube.com/watch?v=UuqSy1jPSUw