Esta técnica en el desarrollo de software proporciona herramientas para desplegar nuevas características a audiencias específicas o probar opciones A/B.
Las arquitecturas de aplicaciones en nube, microservicios, la integración y distribución continuas (CI/CD), automatización de pruebas e infraestructura como código son las tecnologías que permiten un desarrollo ágil y que los equipos de DevOps puedan entregar código a la parte de producción. Partiendo de las publicaciones trimestrales y las integraciones complejas, han llevado el desarrollo de software a una era moderna de desarrollo continuo.
Los desarrolladores siempre se han preocupado por la forma de gestionar la base del código para apoyar las liberaciones frecuentes, la productividad del desarrollador, el desarrollo de características y la refactorización del código para hacer frente a la deuda técnica.
Github posibilita los diferentes paradigmas de desarrollo y ramificación, incluyendo ramas de características, ramas de liberación, desarrollo basado en troncos y flujo de trabajo Gitflow. Las estrategias de ramificación estructuran el código que entra en las construcciones y, por lo tanto, pueden utilizarse para controlar qué herramientas se despliegan para los usuarios finales.
A pesar del debate sobre los enfoques de ramificación, hay un fuerte consenso en que los equipos de desarrollo deben evitar el uso de ramificaciones de larga duración.
Las ramas de larga duración a menudo crean complejas fusiones de código cuando la herramienta está lista para ser integrada en la rama principal.
¿Qué es el feature flagging?
Las ramas controlan el despliegue de código y pueden regular si una herramienta se despliega. Pero esto es sólo un control binario que puede activar y desactivar la disponibilidad de la herramienta. El uso exclusivo de las sucursales para controlar la implementación de las funciones limita la capacidad de un equipo para controlar cuándo se implementa el código, en comparación con el momento en que los líderes del producto lo habilitan para los usuarios finales.
Hay veces en que los propietarios de productos y los equipos de desarrollo deben desplegar herramientas y controlar el acceso a ellas en tiempo de ejecución. Por ejemplo, es útil experimentar y probar las funciones con segmentos específicos de clientes o con una fracción de la base de usuarios.
El marcado de características es una capacidad y un conjunto de herramientas que permiten a los desarrolladores envolver las características con banderas de control.
Una vez que los desarrolladores despliegan el código de la característica, las banderas les permiten alternar, probar y desplegar gradualmente la característica con herramientas para controlar si y cómo aparece a los usuarios finales.
El marcado de las herramientas permite una entrega progresiva al activar una herramienta de forma lenta y controlada. También impulsa la experimentación. Las características pueden ser probadas con los usuarios finales para validar el impacto y la experiencia.
Jon Noronha, vicepresidente de productos de Optimizely, señala que “los equipos de desarrollo deben moverse rápido sin romper las cosas. La entrega progresiva ayuda a aislar las roturas en pequeños trozos y a reducir el radio de explosión que puede derribar aplicaciones enteras”.
Pero, ¿de qué manera los equipos de desarrollo pueden impulsar la experimentación ágil mediante feature flagging?
1. Controlar las características en los entornos de desarrollo y de prueba
A veces las aplicaciones en ambientes de desarrollo o de prueba han enviado accidentalmente correos electrónicos a usuarios internos, o peor aún, a clientes externos, debido a una configuración incorrecta; otras se ha ejecutado un trabajo por lotes cuando no debía hacerse; en otras ocasiones una aplicación ha procesado tarjetas de crédito cuando los probadores beta estaban probando nuevas capacidades.
Estos pueden ser ajustes de configuración que son fáciles de habilitar o deshabilitar si sólo hay unos pocos entornos. Pero, ¿qué pasa si, además de los entornos de desarrollo y prueba, hay también entornos de demostración para pruebas de clientes? ¿Qué pasa si se quiere que las aplicaciones en los entornos de demostración envíen correos electrónicos a una lista específica de dominios, o quiere probar transacciones de pago específicas?
No podrá hacer este nivel de configuración en las pruebas a nivel de código o de sistemas una vez que haya muchas variables, ajustes de configuración y propietarios fuera de la TI necesarios para controlarlos.
El feature flagging es una forma de habilitar estos controles y puede ser más fácil que las herramientas administrativas de codificación personalizada.
2. Pruebas alpha y beta de la experiencia del usuario, el diseño y el lenguaje
Los diseñadores, normalmente, quieren probar las interfaces de usuario y los diseños de las herramientas con los usuarios finales para medir su facilidad de uso e impacto. Los desarrolladores y diseñadores pueden probar diferentes diseños de varias maneras para validar cuáles obtienen más tracción.
Un ejemplo es la implementación de una acción llamada “compre ahora”. Se prueba con diferentes gráficos, estilos de botones y texto para ver qué enfoque genera más clics.
La aplicación permite a los usuarios ordenar los resultados de la búsqueda por varias dimensiones. Un diseñador puede probar diferentes controles para soportar la clasificación en varios niveles y ver qué enfoque le gusta más a los usuarios.
Permitir que los usuarios establezcan controles de privacidad y configuren aplicaciones puede ser difícil, especialmente al decidir los niveles de lenguaje o controles. Probar varios enfoques es una forma de permitir a los usuarios expresar qué enfoque es más fácil de entender y controlar según sus necesidades.
3. La prueba alfa y beta de la nueva tecnología
A veces los desarrolladores necesitan probar nuevos servicios, bibliotecas o kits de desarrollo de software. Otras veces, una actualización disponible incluye nuevas capacidades. ¿Cómo deberían los propietarios de productos ágiles y los equipos de desarrollo saber qué componentes y capacidades están listos para las aplicaciones críticas?
Una forma de eliminar las conjeturas es implementar herramientas, controlarlas con feature flagging y liberarlas como herramientas alfa. Los desarrolladores pueden habilitar las herramientas alfa para que un pequeño grupo de empleados internos proporcione información sobre las nuevas capacidades. Una vez que el equipo de desarrollo aborda cualquier problema o riesgo, el propietario del producto puede habilitar la herramienta para los beta-testers internos y externos.
4. Validar el rendimiento aumentando lentamente el acceso a las nuevas capacidades
Una variante de las pruebas alfa y beta es cuando los equipos de desarrollo aumentan lentamente el acceso a una nueva capacidad para asegurar su fiabilidad, rendimiento y robustez. Dependiendo de las herramientas de feature flagging utilizadas, puede haber diferentes niveles de información y controles disponibles para gestionar un despliegue incremental. Algunos casos de uso avanzado incluyen:
- Si se detectan errores, disminuir el número de usuarios que ven la nueva capacidad hasta que se resuelvan los problemas. Los errores pueden provenir de entradas de usuarios que no están suficientemente validadas o de errores de servicios, microservicios y bases de datos nuevos o actualizados de terceros.
- Reducir la disponibilidad de la función si el tiempo de respuesta aumenta por encima de un umbral definido. Un enfoque relacionado para cuando los equipos no pueden cargar la prueba adecuadamente incluye aumentar lentamente la disponibilidad de una nueva característica hasta que se valide el rendimiento.
- La validación de la respuesta a los algoritmos de aprendizaje automático e inteligencia artificial, como los chatbots, las interfaces de lenguaje natural, los algoritmos de reconocimiento de imágenes y los controles de voz. Las aplicaciones pueden programarse con banderas de características avanzadas para controlar qué casos de uso se habilitan a medida que se prueban y mejoran los algoritmos.
5. Desplegar características por geografía, idioma u otros segmentos de clientes
Una consideración importante es la activación de herramientas para segmentos específicos de clientes. Por ejemplo, una herramienta puede estar lista para ser expuesta a los usuarios en los Estados Unidos, pero la reglamentación impide que se utilice en la Unión Europea.
Otro ejemplo son las herramientas que requieren implementaciones específicas para cada idioma; las banderas de características pueden habilitar los idiomas seleccionados. Es posible que los propietarios de los productos deseen habilitar nuevas herramientas para los usuarios primerizos, los clientes de bajo riesgo u otros grupos demográficos.
Aunque el feature flagging ofrece varias opciones para desplegar o configurar lentamente la disponibilidad de las herramientas, es importante utilizarlas para estos fines.
El uso de indicadores de características como sustituto barato de la aplicación de la lógica empresarial y los parámetros conexos puede crear problemas de apoyo a la aplicación. Además, es importante catalogar las banderas y podarlas cuando ya no se necesiten.
Dado que los desarrolladores de hoy en día deben probar las nuevas capacidades más rápidamente, el feature flagging proporciona la posibilidad para experimentar y desplegar nuevas capacidades con menos riesgos.
–Isaac Sacolick, CIO EEUU.
