El Arte de la Activación de Funciones

Hola, mi nombre es Diani Yedono y llevo más de una década desarrollando software. Me gustaría compartir una práctica efectiva llamada funcionalidad de bandera que he estado utilizando para integrar y desplegar mi código.

Comencemos pensando en el pasado. ¿Recuerdas ese momento en que ocurrió una falla del sistema justo después de un gran lanzamiento? Si nunca has experimentado eso, espero que nunca tengas que hacerlo porque es realmente horrible. Este comentario muestra a una persona pidiéndole a otra persona que imagine que desplegaron una nueva versión de su sistema de gestión de clientes y 15 minutos después la tienda en línea se cae.

A veces, los cambios en un código no afectarían a ninguna otra parte del sistema de software. Sin embargo, en muchos casos, incluso un pequeño cambio puede afectar inesperadamente a otras partes. Y eso es bastante normal. Hay muchos procesos que las personas utilizan para asegurarse de que el software esté protegido de las migraciones introducidas por cualquier cambio de código. Uno de los procesos es tener ramas de funcionalidad de larga duración. Cada una de las ramas se revisa y prueba exhaustivamente antes de fusionarse. Sin embargo, esto puede llevar a otro tipo de problema. Este comentario muestra a un desarrollador que intenta fusionar su rama en la principal. Primero, extraen los cambios de la principal a su rama. Una vez que están satisfechos, se preparan para fusionar su rama de vuelta en la principal. Sin embargo, otro desarrollador acaba de fusionar un gran conjunto de cambios en la principal. Fusionar cambios grandes puede generar conflictos de fusión y eso puede mantener a los desarrolladores despiertos por la noche. Y no es una práctica sostenible.

Estos problemas han llevado a las personas a comenzar a practicar la integración continua, donde los desarrolladores integran continuamente sus cambios de código en la rama principal, poco a poco y de manera regular. Pero, ¿qué sucede si la nueva función tarda mucho tiempo en desarrollarse? ¿Cómo podemos fusionar código a medio cocinar sin afectar a los usuarios o consumidores del software?

Afortunadamente, Virtuflex puede ayudarnos. Virtuflex se ha utilizado para muchos propósitos, algunos de los cuales no forman parte de esta charla. Por lo tanto, esta charla no trata sobre el uso de Virtuflex para lanzamiento canario, pruebas A-B o interruptores Kailh. Pero esta charla trata sobre el uso de Virtuflex para la integración continua, que consiste en fusionar continuamente los cambios de código en la rama principal o tronco, y el despliegue continuo, que consiste en desplegar continuamente los cambios de código de manera segura en producción.

Ahora veamos un ejemplo de aplicación web que va a utilizar Virtuflex. Esta es una aplicación web que almacena una colección de cómics digitales. Tiene una función, que es servir un cómic aleatorio al usuario. Inicialmente, el sitio web utiliza un generador de números aleatorios matemáticos. Luego se decide tener una nueva función y utilizar IA para servir un cómic aleatorio a los usuarios. Y esta IA puede servir el cómic aleatorio dependiendo del clima, por ejemplo, o dependiendo de las tendencias en el mundo. Solo estoy inventando algunas nuevas funciones aquí. El generador de números aleatorios necesita ser cambiado para utilizar IA. Y eso puede llevar un tiempo.

Durante el desarrollo ascendente, queremos mostrar el progreso del sistema de IA. Por ejemplo, en un entorno de desarrollo, UAT o QA. Sin embargo, aún no queremos lanzar esta función a medio cocinar a producción. Por lo tanto, necesitamos una forma de utilizar tanto el generador de números aleatorios matemáticos como el generador de números aleatorios basado en IA, dependiendo del entorno.

Este es el código inicial que utiliza un generador de números aleatorios matemáticos para servir un cómic aleatorio. Ahora, veamos cómo el feature flag puede hacer que la aplicación web sirva un cómic tanto del generador de números aleatorios matemáticos como del generador de números aleatorios basado en IA. En la línea seis, verificamos un feature flag llamado feature flag AI randomizer. Cuando está activado, utilizamos el generador de números aleatorios basado en IA para servir el cómic. Cuando está desactivado, utilizamos el generador de números aleatorios matemáticos en su lugar. El feature flag se almacena como una variable de entorno. En el entorno de desarrollo, el valor se establece en activado, mientras que en producción, el valor se establece en desactivado. De esta manera, podemos construir y desplegar de manera segura el código del generador de números aleatorios basado en IA poco a poco y de manera regular tanto en desarrollo como en producción. Se puede probar continuamente en desarrollo sin afectar a los usuarios de producción. Una vez que la función del generador de números aleatorios basado en IA está completa, podemos activar el flag en producción. Ahí es cuando lanzamos la función. Sin embargo, el código en sí ha estado inactivo en producción durante un tiempo. Así es como se utiliza el feature flagging. Este ejemplo es para el feature flagging del backend. Una ventaja de esta técnica es que es muy versátil y se puede utilizar en otras partes del software. Por ejemplo, en el código del front-end de una aplicación web o una aplicación móvil.

Bien, ¿qué hay de las pruebas automatizadas? ¿Cómo vamos a probar las funciones con flags? Veamos la prueba para este código. Esta es la prueba inicial cuando la aplicación web solo utiliza el generador de números aleatorios matemáticos. Cuando se llama a la API de números aleatorios, debe devolver un cómic falso, que es el único cómic almacenado en el almacenamiento de datos de prueba. Cuando se introduce el flag, establecemos explícitamente el flag en desactivado para la prueba existente. Luego agregamos una prueba cuando el flag está activado. De esta manera, tenemos pruebas automatizadas tanto cuando el flag está activado como cuando está desactivado. Para este ejemplo en particular, la prueba es similar. Devuelven el cómic falso tanto cuando el flag está activado como cuando está desactivado. Esto se debe a que solo tenemos un cómic falso en nuestro almacenamiento de datos de prueba. En muchos casos, una nueva función tiene un comportamiento diferente y, por lo tanto, pruebas diferentes cuando el flag está activado y desactivado.

Entonces, acabamos de repasar el arte secreto del feature flagging. En resumen, comenzamos introduciendo el flag, probamos tanto cuando el flag está activado como cuando está desactivado, y luego escribimos el código de implementación tanto cuando el flag está activado como cuando está desactivado. Nos aseguramos de que el flag esté activado en DEV y desactivado en PROD. Luego desplegamos el código en DEV y también lo desplegamos en producción, y estará inactivo en producción porque el flag está desactivado. Una vez que la función está completa y queremos lanzarla, activamos el flag en PROD. Y una vez que estamos seguros de que la función ha estado comportándose de manera esperada en PROD durante un tiempo, podemos eliminar el código de implementación cuando el flag está desactivado, eliminar la prueba cuando el flag está desactivado. Y una vez que estamos seguros de que el flag no se utiliza en ningún lugar, lo eliminamos. Así es el arte secreto del feature flagging. Muchas gracias por su tiempo, y comencemos con el feature flagging.