He estado trabajando en un proyecto donde el ritmo de desarrollo era mucho más rápido que nuestro proceso de QA. Esa sensación de desplegar código a diario mientras las pruebas y la aceptación del cliente se hacen en lotes es agotadora. Llegó un punto en que yo mismo evitaba desplegar cambios escritos hace una o dos semanas por miedo a que algo fallara después de las pruebas y ya hubiera integrado otras cosas. Hacer rollback de todo, cherry pick de commits y sufrir conflictos durante una incidencia en producción no es una opción segura ni sostenible.
La solución que resolvió la mayoría de estos dolores fueron las banderas de características combinadas con configuración dinámica a nivel de usuario. No bastaba con interruptores globales on off. Necesitaba poder activar comportamientos solo para determinados probadores o clientes sin afectar al resto. Por eso opté por dos niveles de control: global y por usuario.
Ejemplos reales que lo hacen tangible
Pruebas de pagos En producción el mínimo por hora estaba fijado en 60. No quería pagar esa cifra cada vez que probábamos un flujo de pago. Implementé configuración por usuario para ajustar el mínimo y así poder ponerlo a 1 para pruebas. Esto es más configuración dinámica que una bandera booleana, pero se maneja con el mismo mecanismo.
Nueva pasarela de créditos Cuando introdujimos créditos dentro de la app se dejó de depender exclusivamente de Stripe. El dinero es lo más crítico en cualquier producto, así que necesitábamos un interruptor de emergencia para deshabilitar los pagos instantáneamente si algo iba mal y volver a activarlo cuando todo estuviera validado.
El infierno del rollback Al entregar con prisas aparecen los bugs. Has desplegado, salta un fallo y ya mezclaste cambios. Hacer rollback implica lidiar con merges y riesgos extra durante la incidencia. Con banderas de características basta con desactivarlas. No necesitas sacar una nueva release ni invadir el proceso de CI para mitigar un problema.
El problema real no es solo la flexibilidad. Es que el proceso de release queda fuertemente acoplado al despliegue. Para cambiar algo hay que crear otra versión y pasar por todo el ciclo de pruebas, lo que consume tiempo y dinero. Mi alternativa fue esconder el impacto detrás de banderas desde el primer commit. Eso me permitió desplegar código incompleto a producción si la bandera estaba desactivada y activarla solo para usuarios concretos cuando quisiera probar.
Cómo lo implementé de forma sencilla
Lo más importante es seguir la regla KISS. No necesitas un sistema monstruoso para empezar. Lo que sí necesitas es: almacenamiento para las banderas y valores de configuración, un panel de administración para CRUD y una forma simple de consultarlas desde tu código. En mi caso uso un bus de eventos en memoria y un contexto por petición que carga las banderas globales y las específicas del usuario.
La lógica de comprobación es clara y con precedencia definida: si existe una bandera para el usuario esa prevalece sobre la configuración global; en caso contrario se consulta la bandera global; si no existe se considera deshabilitada. Con esto tienes un comportamiento predecible y fácil de razonar durante incidentes.
Lo que en verdad construí
Para ser honesto, llamé a esto banderas de características pero en la práctica es más un sistema de configuración dinámica. En producción uso valores tipados como MINIMUM_TIME_REQUIRED_BEFORE_BOOKING_IN_HOURS, CAPTIONER_HOURLY_RATE_MIN y CAPTIONER_HOURLY_RATE_MAX. Son variables que puedo ajustar sin desplegar y que afectan políticas de reserva y validaciones de precio.
Lecciones aprendidas y próximos pasos
Build vs buy: empecé construyendo porque era más rápido y relativamente sencillo. Problema que debí prever desde el inicio: la expiración automática de las banderas. Las banderas son temporales por definición. Sin un TTL se convierten en deuda técnica y terminas con un cementerio de banderas olvidadas. En un buen sistema cada bandera debería tener fecha de caducidad y acciones asociadas al expirar: auto deshabilitar y notificar al equipo, forzar una decisión de limpieza o eliminarse automáticamente. Esto evita acumular 50 o más banderas sin sentido.
Qué añadiría ahora: implementación de TTL con limpieza automatizada, herramientas para auditar el uso de banderas y métricas que permitan ver quién y cuándo activa cada configuración, y reetiquetado de la solución a configuración dinámica con toggles de características para reflejar mejor su alcance.
Cómo encaja esto con Q2BSTUDIO
En Q2BSTUDIO ayudamos a empresas a diseñar e implementar soluciones como estas dentro de proyectos de aplicaciones a medida y software a medida. No solo desarrollamos la funcionalidad, sino que también asesoramos sobre buenas prácticas en despliegues, seguridad y operabilidad. Si necesitas una plataforma que incluya configuración dinámica a nivel de usuario o banderas de características integradas en una app a medida conoce más sobre nuestros servicios en desarrollo de aplicaciones y software multimplataforma. También trabajamos inteligencia artificial aplicada, agentes IA y soluciones de IA para empresas que pueden beneficiarse de toggles dinámicos para experimentar modelos sin afectar a todos los usuarios; descubre nuestras propuestas de inteligencia artificial.
Además ofrecemos servicios de ciberseguridad para proteger puntos críticos como flujos de pago, auditoría de configuración y pruebas de penetración, infraestructuras en servicios cloud aws y azure, y soluciones de servicios inteligencia de negocio y power bi para medir el impacto de cambios controlados por banderas. Palabras clave que aplican a estos servicios: aplicaciones a medida, software a medida, inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio, ia para empresas, agentes IA y power bi.
Conclusión y llamada a la acción
Implementar banderas de características y configuración dinámica puede transformar tu proceso de entrega: despliegues más rápidos, incidentes más manejables y experimentación controlada a nivel de usuario. Si tu gestión de configuración todavía obliga a desplegar una nueva versión para cambiar un valor, quizá sea el momento de replantear la arquitectura. En Q2BSTUDIO podemos ayudarte a diseñar e integrar estos mecanismos dentro de tus aplicaciones a medida y procesos de DevOps, con foco en seguridad, escalabilidad y observabilidad.
Me interesa saber cómo gestionas la configuración en tus proyectos. ¿Sigues haciendo despliegues para cambiar un solo parámetro o ya usas toggles y configuración por usuario? Comparte tu experiencia y si quieres podemos conversar sobre cómo integrar esto en tu producto.