Banderas de funcionalidades: tipos, ciclo de vida y gobernanza para equipos

Banderas de funcionalidades: tipos, ciclo de vida y gobernanza para equipos

Las banderas de funcionalidades permiten poner código en producción sin exponerlo, activarlo para unos pocos usuarios y desactivarlo en segundos si algo falla, todo ello sin volver a desplegar. Adoptarlas es la parte fácil. Gestionarlas bien, con tipos, responsables y fechas de caducidad claros, además del hábito de eliminar lo que ya no se necesita, es lo que distingue una red de seguridad de una segunda base de código sin documentar.

Este artículo aborda las banderas de funcionalidades como una disciplina. No es una comparación de estrategias de despliegue. Para conocer la visión más amplia de las versiones, consulte nuestra guía sobre gestión de versiones. Aquí nos centramos en lo que debe decidir antes de implementar la primera bandera y en lo que debe hacer cumplir después de la número cien.

Conclusiones principales

• Una bandera de funcionalidades separa el despliegue (el código llega a producción) de la versión (los usuarios pueden verla). Esa separación es todo su valor.
• No todas las banderas son iguales. Las banderas de versión, experimentación, operativas y de permisos tienen distintas duraciones y responsables, por lo que deben gestionarse de forma diferente.
• Cada bandera necesita un responsable, un propósito y un plan de eliminación desde el día en que se crea. Las banderas obsoletas se convierten en deuda técnica y, en el peor de los casos, en una interrupción del servicio.
• Trate los cambios de banderas en producción como cambios de código: control de acceso, revisión, registros de auditoría y monitorización.
• El propio servicio de banderas es una dependencia. Diseñe el sistema pensando en el día en que no esté disponible.

Índice

• Qué hacen las banderas de funcionalidades y qué no hacen
• Cuatro tipos de conmutadores de funcionalidades, cuatro duraciones
• El ciclo de vida de una bandera, desde su creación hasta su eliminación
• Gobernanza: quién puede cambiar qué en producción
• Estrategias de lanzamiento y lanzamiento porcentual
• Dónde fallan las banderas de funcionalidades
• Cómo elegir herramientas de gestión de banderas de funcionalidades
• Cómo ayudamos con los programas de banderas de funcionalidades
• Las banderas de funcionalidades son una disciplina, no un interruptor
• Preguntas frecuentes
• Fuentes

Qué hacen las banderas de funcionalidades y qué no hacen

Una bandera de funcionalidades, también llamada conmutador de funcionalidades, es una lógica condicional evaluada en tiempo de ejecución que decide si se ejecuta un bloque de código para un usuario determinado. Su estado puede cambiarse mediante una configuración externa, sin modificar ni volver a desplegar la aplicación.

Esto proporciona una separación clara. El despliegue pone el código en producción. La versión hace que la funcionalidad esté disponible para los usuarios. Con las banderas, los equipos pueden poner código en producción mientras restringen su disponibilidad, y después activarlo para usuarios seleccionados sin reiniciar ni realizar un nuevo despliegue. Los equipos utilizan esta separación para el desarrollo basado en troncos, los lanzamientos graduales, los experimentos, el acceso premium y el control operativo.

El desarrollo basado en troncos merece una explicación. Como el trabajo sin terminar puede fusionarse detrás de una bandera desactivada, las ramas se mantienen cortas y disminuyen los problemas de integración. El precio es que la rama principal ahora contiene rutas de código que no están activas y alguien debe encargarse de ellas.

Lo que no son las banderas: configuración. La configuración estática de la aplicación suele ser duradera y se carga al iniciarse, mientras que las banderas son dinámicas, de corta duración y se actualizan durante la ejecución. Mezclar ambas cosas es la forma de acabar con una cadena de conexión a una base de datos en un panel de conmutadores que pueden editar treinta personas.

¿Cómo se evalúa realmente un indicador? Un SDK de su aplicación obtiene las reglas, las evalúa con respecto al usuario y al contexto, y aplica el resultado. Un ejemplo documentado: un SDK de servidor almacena en caché la configuración y consulta las actualizaciones cada 60 segundos; las evaluaciones suelen tardar menos de un milisegundo. Obtener y resolver son pasos distintos, y los SDK pueden obtener datos al iniciarse, en segundo plano o durante una sesión. Este detalle será importante más adelante, cuando lleguemos a los modos de fallo.

Cuatro tipos de indicadores de funcionalidades, cuatro ciclos de vida

La mayoría de los problemas con los indicadores comienzan cuando un equipo trata todos los interruptores de la misma manera. La taxonomía de los indicadores ampliamente citada de Martin Fowler los separa según cuánto tiempo permanecen activos y qué tan dinámicos son. En la práctica, consideramos útiles cuatro categorías operativas:

Indicadores de lanzamiento

Son los más habituales. Existen para que el código incompleto pueda integrarse y para que un lanzamiento sea una decisión de negocio, no un evento de despliegue. Deben ser los indicadores de menor duración que tenga. Si un indicador de lanzamiento es más antiguo que la funcionalidad, algo salió mal.

Interruptores de apagado

Un interruptor de apagado es un control instantáneo de activación o desactivación para todos los usuarios que permite deshabilitar en cuestión de segundos una funcionalidad o dependencia que funciona incorrectamente, sin necesidad de volver a desplegar. La orientación de DevOps de Microsoft señala que un indicador de desactivación rápida puede restablecer un comportamiento fiable y controlar cambios arquitectónicos o de infraestructura, además de funcionalidades de la interfaz de usuario.

Los interruptores de apagado son la excepción legítima a la regla de corta duración. Fowler describe los de larga duración como indicadores operativos que permiten a los operadores degradar correctamente las funcionalidades no esenciales bajo una carga inusualmente alta. Su observación sobre la velocidad es la que debe recordar: si para desactivar algo se necesita una nueva versión, el interruptor ha fallado en su única función. Coloque un interruptor de apagado alrededor de cada llamada costosa a terceros, de cada canalización de datos nueva y de cada funcionalidad que intervenga en pagos o correo electrónico, y practique su uso.

Indicadores de experimentos y permisos

Los indicadores de experimentos duran exactamente lo mismo que la prueba. Decida la métrica y la fecha de finalización antes de activar el indicador. En realidad, los indicadores de permisos son derechos de producto disfrazados de indicadores. Si el acceso depende del plan de un cliente, modélelo como un derecho con sus propias pruebas, no como un interruptor que alguien podría eliminar durante la limpieza.

El ciclo de vida de un indicador, desde su creación hasta su eliminación

La documentación de Atlassian describe un ciclo de vida típico de creación, configuración de la segmentación, evaluación en tiempo de ejecución y limpieza. La mayoría de los equipos hace bien las tres primeras etapas y omite la cuarta. Un ciclo de vida viable tiene seis etapas:

1. Proponer. Registre el nombre, el tipo, el responsable, el propósito y la fecha prevista de eliminación del indicador. Los nombres deben ser únicos y lo bastante descriptivos como para que una persona recién incorporada pueda deducir qué hace el indicador.
2. Desarrollar. Mantenga la evaluación del indicador separada de la lógica de negocio, de modo que la decisión se encuentre en una única capa sencilla en lugar de estar dispersa por las funciones. Defina un valor predeterminado seguro para cuando el servicio de indicadores no pueda responder.
3. Probar. Pruebe ambas rutas de código. Un indicador con una sola rama probada es un error esperando su turno.
4. Desplegar gradualmente. Avance según el patrón de despliegue gradual elegido mientras supervisa las tasas de error, la latencia y las métricas de negocio.
5. Estabilizar. Una vez que la funcionalidad esté al 100 % y no dé problemas, el indicador habrá cumplido su función.
6. Eliminar. Elimine el indicador, la ruta de código descartada y las pruebas correspondientes. Después, confirme que nada haga referencia al indicador en el código base.

Los pasos cinco y seis son donde se demuestra la disciplina. Las investigaciones sugieren que el problema es real y no meramente teórico. Un estudio empírico de 2021 sobre 12 proyectos de código abierto en Python y una encuesta a 61 profesionales concluyeron que el 75 % de los componentes de interruptores se eliminó en un plazo de 49 semanas, lo que también significa que una proporción significativa no se eliminó y que algunos indicadores de larga duración nunca estuvieron destinados a mantenerse. Esos supervivientes son los que añaden riesgos silenciosamente.

Cómo prevenir la deuda de indicadores

La deuda de indicadores es la acumulación de interruptores que ya no cumplen ninguna función, pero siguen determinando el comportamiento del código. El modelo de calidad arc42 incluye la deuda de interruptores, los estados de prueba obsoletos y las colisiones entre interruptores que interactúan entre los modos de fallo de este enfoque. Algunas prácticas ayudan a mantenerla bajo control:

• Fechas de caducidad en el registro del indicador. Alerta al responsable cuando se supere esa fecha y vuelve a alertarlo cuando el indicador esté atrasado.
• Un ticket de limpieza creado junto con el indicador. No después. Cuando se cierre el ticket del despliegue gradual, el ticket de eliminación ya debe estar esperando.
• Un límite de indicadores de lanzamiento activos por equipo. Una cifra visible para todos genera una presión saludable.
• Una revisión periódica del código. Harness recomienda alertas para indicadores obsoletos y comprobar si quedan indicadores en el código, algo que una comprobación de CI puede automatizar.

Si su equipo ya arrastra una acumulación de código muerto, se aplica el mismo enfoque de priorización. Nuestra guía sobre remediación de la deuda técnica explica cómo dimensionar y secuenciar ese trabajo.

Gobernanza: quién puede cambiar qué en producción

Un cambio en un indicador en producción es un cambio en producción. Harness recomienda tratar la configuración de los indicadores de funcionalidades como código de producción, con controles de revisión comparables, degradación controlada mediante valores almacenados en caché o predeterminados y compatibilidad con versiones anteriores. La versión práctica para un líder de ingeniería sería la siguiente:

• Acceso basado en roles. No todas las personas que pueden leer los indicadores deberían poder activarlos o desactivarlos en producción. LaunchDarkly incluye un control de acceso granular basado en roles y registros de auditoría entre las capacidades de seguridad para cambios controlados en producción.
• Aprobaciones para indicadores de alto riesgo. Los pagos, la autenticación y la eliminación de datos merecen una segunda revisión antes de cambiar un indicador.
• Registros de auditoría. Debería poder responder quién cambió qué y cuándo, sin tener que preguntar por el chat.
• Disciplina entre entornos. La divergencia de configuración entre preproducción y producción es un modo de fallo documentado, así que compárelas según un calendario en lugar de confiar en que no ocurrirá.
• Nombres y responsables claros. Un indicador sin responsable es un incidente futuro sin nadie a quien llamar.

La seguridad forma parte de la gobernanza

Los indicadores pueden debilitar la seguridad si no se gestionan con cuidado. La guía de pruebas de OWASP advierte que los estados incoherentes de los indicadores pueden debilitar la autenticación, la autorización, la detección de fraude y la limitación de velocidad entre servicios, especialmente durante un despliegue parcial, una reversión o un fallo del servicio de indicadores. También advierte que los indicadores visibles para el cliente no son límites de seguridad. Aplique la autorización en el servidor, evalúe los indicadores sensibles en el servidor y no dependa nunca de un botón oculto como mecanismo de control. Si su aplicación gestiona datos regulados, implique a su responsable de seguridad antes de que el primer indicador afecte a una ruta de acceso.

Estrategias de despliegue y despliegue porcentual

Los indicadores permiten varios patrones de despliegue, y el adecuado depende de su base de usuarios. La documentación de LaunchDarkly describe despliegues por anillos, despliegues porcentuales, canarios, despliegues dirigidos, despliegues por derechos y lanzamientos en la sombra. En términos sencillos:

• Despliegue por anillos: primero el personal interno, después un grupo beta y, por último, todo el mundo. Es adecuado cuando cuenta con una audiencia beta natural.
• Despliegue porcentual: exponerlo al 1 %, después al 5 %, luego al 25 %, y así sucesivamente. Es más adecuado cuando la base de usuarios presenta poca variación o no dispone de un programa beta.
• Canario: un grupo pequeño y representativo para probar la aceptación y la capacidad.
• Despliegue dirigido: cuentas o grupos específicos, útil cuando los clientes dependen unos de otros.
• Lanzamiento en la sombra: el código se despliega y se ejecuta, pero no se publica para el público.

El modelo de despliegue de Azure añade dimensiones útiles: segmentación por usuario, grupo o atributos personalizados como la región, el tipo de dispositivo o el nivel de suscripción, además de la activación programada. AWS expresa bien la lógica: limitar el radio de impacto mientras se realizan pruebas en condiciones reales es mejor que exponer a todos los usuarios de una vez.

Dos reglas hacen fiable el despliegue porcentual. En primer lugar, mantenga constante la asignación para que un usuario que ve hoy el nuevo proceso de pago no vea mañana el antiguo. En segundo lugar, deje por escrito de antemano qué supervisará y qué resultado activará el interruptor de emergencia. Un despliegue sin una condición de detención no es más que un lanzamiento lento.

GitHub describe la posibilidad de habilitar cambios arriesgados para todo el mundo o para un porcentaje de usuarios después del despliegue y, a continuación, deshabilitarlos en cuestión de segundos sin revertir el despliegue. Eso solo funciona si puede ver el efecto rápidamente, por lo que los indicadores y la monitorización van de la mano. Nuestro artículo sobre observabilidad de aplicaciones explica qué debe instrumentar.

Cuándo fallan los indicadores de funcionalidad

Las desventajas son concretas y conviene conocerlas antes de comprometerse.

Código obsoleto y reutilización insegura. El relato de InfoQ sobre el incidente de Knight Capital de 2012 describe cómo se reutilizó un indicador obsoleto mientras el código inactivo permanecía. El resultado fueron aproximadamente 460 millones de dólares en pérdidas en unos 30 minutos. Dos lecciones: elimine el código inactivo y no reutilice nunca el nombre de un indicador antiguo para un comportamiento nuevo.

Complejidad combinatoria. Cada indicador duplica el número teórico de rutas de código. No podrá probarlas todas, así que reduzca al mínimo los indicadores que interactúan y documente sus dependencias. GitHub también enumera riesgos específicos, como consultas de base de datos más lentas, casos límite inesperados en la lógica y valores no válidos en la base de datos.

El servicio de indicadores como punto único de fallo. El informe del incidente de PostHog registra que el 78 % de las solicitudes de evaluación de indicadores de funcionalidad en su región de EE. UU. fallaron durante 1 hora y 48 minutos, y que la amplificación de reintentos y unos controles de estado deficientes prolongaron la situación. Un análisis posterior cubre cuatro incidentes en 10 días que afectaron tanto a la aplicación principal como a la evaluación de indicadores. La lección para sus propios sistemas: las cachés locales y los valores predeterminados de respaldo mantienen las aplicaciones en funcionamiento cuando el sistema de indicadores no lo hace, como señala la guía de buenas prácticas. Pruebe qué hace su aplicación cuando se agota el tiempo de espera de la evaluación de indicadores. No lo descubra en producción.

Evaluación incoherente. El mismo indicador puede resolverse de forma diferente dentro de una sola solicitud si se lee dos veces. Evalúelo una vez en el límite de la solicitud y transfiera el resultado.

Cómo elegir herramientas de gestión de indicadores de funcionalidad

Crear un sistema básico de indicadores es un proyecto de fin de semana. Operarlo de forma segura durante años no lo es, así que decida con pleno conocimiento. Al evaluar plataformas o una solución propia, la lista de funcionalidades de LaunchDarkly es una lista de comprobación útil: cobertura de SDK, indicadores booleanos y multivariantes, segmentación y segmentación por destinatarios, despliegues progresivos, control por entorno, requisitos previos, actualizaciones en tiempo real, interruptores de apagado, RBAC, aprobaciones, registros de auditoría e integraciones.

Además de esa lista, hágase estas preguntas:

1. ¿Qué ocurre cuando el servicio no está disponible? Busque almacenamiento en caché local y un comportamiento de respaldo documentado. Por ejemplo, la página de precios de un proveedor describe SDK que descargan y almacenan en caché la configuración, y evalúan a partir de esa caché.
2. ¿Con qué rapidez se propagan los cambios? ¿Segundos o minutos? ¿Coincide el intervalo de sondeo con sus expectativas para el interruptor de apagado?
3. ¿Puede gestionar los indicadores como código? La interfaz de usuario, la CLI, la API y los flujos de trabajo de Git son importantes cuando tiene más de unas pocas docenas de indicadores.
4. ¿Le ayuda a limpiarlos? Los informes de indicadores obsoletos valen más que otra opción de segmentación.
5. ¿Adónde van los datos de los usuarios? Evaluar los indicadores en el servidor mantiene los datos personales fuera de los sistemas de terceros.

Para equipos pequeños con unas pocas funciones de lanzamiento, un enfoque interno sencillo, con una nomenclatura estricta y fechas de caducidad, puede ser suficiente. A medida que crecen los equipos, los servicios y las necesidades de cumplimiento, las plataformas gestionadas justifican su coste. La respuesta adecuada depende de su arquitectura, y es una buena cuestión que conviene resolver antes de tener doscientas funciones.

Cómo ayudamos con los programas de indicadores de funciones

En Ridiculous Engineering, ingenieros sénior trabajan con su equipo en las decisiones relacionadas con los indicadores de funciones: qué tipos necesitan, cómo integrar la evaluación en su arquitectura, qué modelo de gobernanza se ajusta a su perfil de riesgo y cómo incorporar la limpieza en su flujo de entrega. Tanto si está modernizando un sistema heredado como si está desarrollando algo nuevo, nuestros servicios de consultoría y entrega de software y nuestros servicios de desarrollo de software personalizado se definen según su situación, con precios previa solicitud. También puede consultar nuestros artículos sobre DevOps para conocer prácticas relacionadas.

Los indicadores de funciones son una disciplina, no un interruptor

Los indicadores de funciones le ofrecen algo poco común: la capacidad de realizar entregas de forma continua y aun así retirarlas en cuestión de segundos. Solo cumplen esa promesa cuando cada indicador tiene un tipo, un responsable, una prueba para ambas rutas, un registro de auditoría y una fecha de finalización. Trate el sistema de indicadores como infraestructura de producción, mantenga interruptores de emergencia para los momentos importantes y elimine todo lo demás según lo previsto.

Empiece con poco. Elija una función próxima, asigne un responsable, redacte primero la tarea de eliminación y ejecútela durante todo el ciclo de vida. Lo que su equipo aprenda de ese único indicador dará forma a todas las políticas posteriores.

Preguntas frecuentes

¿Cuál es la diferencia entre los indicadores de funciones y los interruptores de funciones?

Ninguna significativa. Los términos se utilizan indistintamente, y el conocido artículo de Martin Fowler emplea ambos. Algunos equipos reservan «interruptor» para los conmutadores sencillos de activación y desactivación, y «indicador» para los que tienen reglas de segmentación, pero se trata de una convención interna, no de un estándar.

¿Son los indicadores de funciones lo mismo que la configuración?

No. La configuración suele ser de larga duración y se carga al iniciarse, mientras que los indicadores son dinámicos, temporales y se modifican durante la ejecución. Mantenerlos separados evita que los ajustes sensibles acaben en una herramienta diseñada para cambios frecuentes y sencillos.

¿Cuáles son las desventajas de los indicadores de funciones?

Las principales son los indicadores obsoletos que se convierten en deuda técnica, las rutas de código adicionales que multiplican el esfuerzo de prueba y la dependencia del servicio de indicadores. La seguridad es otra preocupación si los indicadores protegen controles de acceso. Los responsables, las fechas de caducidad, los valores predeterminados seguros y la evaluación en el servidor resuelven la mayoría de estos problemas.

¿Cuándo debe permanecer permanentemente un interruptor de emergencia?

Manténgalo cuando proteja frente a un riesgo operativo recurrente, como una dependencia de terceros poco fiable o una función pesada bajo una carga máxima. Documente su uso, pruébelo periódicamente y asígnele un responsable, como a cualquier otro control de larga duración.

Fuentes

• Indicadores de funciones - .NET | Microsoft Learn
• Conceptos básicos de los indicadores de funciones | Atlassian
• ¿Qué son los indicadores de funciones? | Documentación de Confidence
• Interruptores de funciones (también llamados indicadores de funciones) | Martin Fowler
• Comprender la gestión de funciones mediante Azure App Configuration | Microsoft Learn
• Experimentación progresiva con indicadores de funciones | Microsoft Learn
• 11 prácticas recomendadas para crear y escalar sistemas de indicadores de funciones | Unleash
• Sobre la eliminación de los interruptores de funciones (2021)
• Interruptores de funciones | Modelo de calidad arc42
• Prácticas recomendadas para gestionar indicadores | Harness
• Prácticas recomendadas para una gestión eficaz de los indicadores de funciones | Harness
• Evasión de la seguridad mediante indicadores de funciones | Guía de pruebas de seguridad web de OWASP
• Estrategias de implementación y lanzamiento | LaunchDarkly
• Cómo funcionan los indicadores de funciones | LaunchDarkly
• Implementar técnicas de lanzamiento incremental de funciones | AWS Well-Architected
• Cómo entregamos código de forma más rápida y segura con indicadores de funciones | GitHub
• Cuando los indicadores de funciones salen mal | InfoQ
• Interrupción del servicio de indicadores de funciones | PostHog
• Interrupciones recurrentes causadas por indicadores de funcionalidad | PostHog
• Precios | ConfigCat

Recomendado

• Gestión de lanzamientos: cómo los equipos de ingeniería implementan cambios de forma segura
• Optimice sus prácticas de DevOps con conocimientos y herramientas de expertos