Uso de FeatureToggles o FeatureFlags

Introducción

El término de FeatureToggles o FeatureFlags no es precisamente nuevo.
Pero antes de empezar conviene indicar que es posible que el término te pueda resultar extraño, ya que no hay una normalización de uso de su nombre y lo podrás encontrar como FeatureToggles, FeatureBits, FeatureSwitchs, Conditional Feature o FeatureFlippers por poner algunos ejemplos, pero en esencia estamos hablando de lo mismo, si bien lo más habitual es encontrarlo como FeatureToggles o FeatureFlags.

Una de las primeras personas que lo mencionó fue Martin Fowler.
También en su sitio web podemos encontrar otra entrada sobre este término.

Se trata de un término bastante extendido en el desarrollo del Software, e incluso se puede encontrar en la documentación de Microsoft sobre Azure DevOps.

Pero no es ni ha sido el único autor que ha hablado de ello, es más, había gente que usaba técnicas parecidas y que simplemente, no compartieron la idea o no tuvieron el eco que personas como Martin Fowler sí tiene.

¿Qué es FeatureToggles o FeatureFlags?

Llegados a este punto, ¿qué es FeatureToggles o FeatureFlags?.

Feature Toggle es un mecanismo que nos permitirá modificar el comportamiento dinámico de una aplicación vía configuración (o similar) sin necesidad de recompilar ni realizar cambios dentro de nuestro código, o debiendo ejecutar tareas de marchas atrás en un despliegue.
El principal objetivo de Feature Toggle es permitir que el equipo de desarrollo entregue nueva funcionalidad a los usuarios de forma rápida, controlada, flexible y segura, sin necesidad de realizar tareas de infraestructura o despliegue.

Para lograr el propósito detrás de Feature Toggle, deberemos preparar un mecanismo con el que podamos habilitar o deshabilitar una característica o funcionalidad en tiempo de ejecución.
Es decir, va a actuar en un modo binario de tipo on/off que nos ayudará a realizar la operación de habilitar y deshabilitar la funcionalidad que queremos utilizar o no.
Hasta aquí y de forma genérica lo que significa o lo que hay detrás de este término.

En mi opinión, el valor por defecto de un flag o toggle debe ser siempre falso (funcionalidad deshabilitada).

Ejemplo teórico práctico

Profundizando en un ejemplo ficticio de código de una aplicación, vamos a asumir que tenemos una aplicación con una función y dentro de esta función una determinada funcionalidad:

Ahora supongamos que queremos probar una funcionalidad determinada en producción, pero no tenemos claro el impacto de la misma.
No sabemos si se va a comportar como esperamos, o queremos estudiar si va a tener el uso o demanda que buscamos, o si simplemente, va a tener un rendimiento aceptable.
Parece lógico que tener una opción para habilitar o deshabilitar esa funcionalidad podría resultarnos de ayuda.

Por poner un segundo ejemplo, supongamos que hemos preparado una funcionalidad nueva.
Aunque la desplegaremos de forma global, inicialmente la habilitaremos para el entorno de integración estando deshabilitada (por defecto siempre) en el de producción.
De forma controlada y en integración podemos comprobar cómo se comporta, su rendimiento, etc.

Otro posible ejemplo es el de tener una funcionalidad nueva que queremos ir poniendo en funcionamiento en grupos de usuarios concretos.
Empezaremos habilitando la funcionalidad nueva a un grupo de usuarios declarados como beta-testers.
Si todo va como esperamos, ampliaremos su uso a un grupo de usuarios de ámbito funcional o de negocio interno.
Si todo va como esperamos, incorporaremos a grupos de usuarios de clientes de confianza.
Y si finalmente todo va como se espera, abriremos la funcionalidad al público global.

Hay muchos posibles ejemplos como aplicación de campañas concretas temporales, estudio de comportamientos y demanda (poner un banner en una parte de la pantalla para ver si se compra más un artículo), etc.

Las estrategias de cómo llevar a cabo todas estas acciones son muy amplias y diversas.
Dependerá del contexto, la dificultad o no para llevarlas a cabo, las herramientas para estudiar el comportamiento y resultados que nos permitan habilitar o no una funcionalidad, etc.

Lo que tendremos claro es que en cualquier momento y ante cualquier problema eventual, estaremos preparados para afrontar una marcha atrás rápida.

Dicho todo esto, del ejemplo ficticio anterior de código de una aplicación, asumimos un cambio de la misma de la siguiente forma:

Según este ejemplo ficticio, nuestro Toggle o Flag permitirá habilitar la nueva funcionalidad o no.
En este ejemplo habríamos refactorizado nuestro código para llevarnos la funcionalidad actual a un método y crearemos un nuevo método con la nueva funcionalidad.
El Toggle o Flag será utilizado por el método inicial a la parte de la funcionalidad (actual o nueva) que nos interese ejecutar en un momento dado.

Conclusiones

El uso de FeatureToggles o FeatureFlags es una técnica que nos puede resultar de interés y ventajosa en determinadas circunstancias.

Sin embargo, todo esto que he comentado gira alrededor de conceptos, estrategias y técnicas arquitectónicas, de infraestructura y de Devops muy variadas ya existentes y muy utilizadas por grandes y pequeñas empresas.
Desde BlueGreenDeployment, pasando por Canary Release, o Targeted Release,… etc.

Los conceptos de los que hablo en este artículo, tienen más cabida en el mundo del desarrollo y menos en el de operaciones.
De hecho, la estrategia de Canary Release por ejemplo es diferente, aunque hay mucha gente que la confunde con FeatureToggles o FeatureFlags.
FeatureToggles y FeatureFlags son conceptos y estrategias que muchas veces los encontrarás en A/B Testing.
Pero su uso no sólo debe o puede reducirse a A/B Testing.

Aún y así, no hay balas de plata ni todo son clavos.

El contexto en el que nos encontremos también, la infraestructura con la que contemos, las herramientas de análisis de datos e información, el propio equipo, etc., son aspectos que debemos tener en cuenta siempre.
Pensemos en todo esto como estrategias, planteamientos, opciones, ideas, formas de trabajar y de buscar soluciones que nos pueden resultar muy útiles en determinadas circunstancias sin correr excesivos riesgos.

Happy Coding!