 Además de técnicas avanzadas de deploy como Canary, Azulverde e Incremental, hay enfoques de entrega progresiva que reducen riesgos, como feature flags, al practicar la entrega progresiva. La entrega progresiva es una faceta de la entrega continua y es la capacidad de probar en vivo mientras controlas tu audiencia. En cuanto a quien puede usar o ver las actualizaciones de tu aplicación con mucha meticulosidad, este enfoque también se puede pensar como experimentación de desarrolladores, beneficios de las feature flags, disminuir riesgos al evitar interrupciones no programadas, controlar a la audiencia de manera meticulosa y opcionalmente usar las feature flags junto con despliegue Canary, facilidad de uso por su configurabilidad sencilla, soporte de listas de usuarios, servicio de las feature flags integrado e instrumentación sencilla, lenguaje agnóstico, soporta los principales lenguajes de programación, mejor cumplimiento y auditoría por grabación automática de acciones de feature flags por la plataforma de KitLab. En esta demostración técnica, veremos cómo Rachel, supervisora de entregas, crea y usa una feature flag en su afán de adoptar este enfoque progresivo de entrega. Rachel crea una nueva feature flags y lo nombra con la abreviatura productos en orden alfabético, feature flags. Las feature flags tienen estrategias específicas a su entorno que deben definirse, así que Rachel procede a definir estas estrategias. Crea una para la producción y procede a crear estrategias para otros entornos, una vez que defina todas las estrategias y crea las feature flags. Puede habilitarla o deshabilitarla mediante un control deslizante en la ventana feature flags. También, para que las feature flags puedan ser utilizadas por este proyecto, la URL de la API y la ID de la instancia del servicio de feature flags deben compartirse con los desarrolladores. Rachel copia estos dos valores para compartir después. Rachel quisiera usar las feature flags, las cuales segmentan a la audiencia, que verá una nueva función de manera controlada en un entorno específico. Abre la ventana de las feature flags y elige productos en orden alfabético, que tiene tres estrategias y una lista de usuarios, productos en orden alfabético con dos usuarios. Michael arroba cfl.rr.com y Mary arroba cfl.rr.com. La primera estrategia usa un porcentaje de implementación del 50% según la identificación disponible del usuario para el entorno de producción. La segunda es para usuarios y lista de usuarios. Productos en orden alfabético, lista de usuarios para el entorno de ensayo. La tercera es para las feature flags a un usuario específico. Tomas arroba cfl.rr.com para el entorno de revisión, que es un entorno efímero para validar actualizaciones de las aplicaciones antes de que se fusionen a la rama principal, dado que hay múltiples entornos de revisión por la cuantía de ramas de funciones concurrentes en las que trabajan los desarrolladores. Rachel busca entre los entornos de revisión existentes y selecciona el correcto al que se aplicará esta estrategia. Las feature flags ayudan a ver hecho a reducir el riesgo, permitiendo hacer pruebas de control y separar la entrega de funcionalidades del lanzamiento al cliente. Ha hecho le gustaría comprobar la estrategia de feature flags en acción en el entorno de revisión. Abre la aplicación en el entorno de revisión e inicia sesión con Tomasarroba.gmail.com. Confirma que Tomas tenga la lista de productos en orden alfabético y por nombre de producto. También nota en el entorno de revisión que la aplicación tiene un fondo naranja. Cierra esta sesión e inicia sesión como peterarroba.gmail.com. Observa que Peter no ve la lista de productos en orden alfabético, porque la estrategia de feature flags para el entorno de revisión es solo una funcionalidad que tiene Tomas. Rachel ahora abre la aplicación en el entorno de producción para ver si la estrategia de deployment del 50% según la ID disponible se está aplicando. Hay seis valores de nombres de usuario que admite esta aplicación. Primero inicia sesión como Peter y ve que no obtiene la funcionalidad. Luego inicia sesión como Magic y él sí recibe la funcionalidad. Procede a iniciar sesión como Michael y también recibe la funcionalidad. Luego inicia sesión como Henry y confirma que no recibe la funcionalidad. Inicia sesión como Mary y confirma que no recibe la funcionalidad. Y finalmente inicia sesión como Tomas que sí recibe la funcionalidad. Si recuerdas quién recibió y quién no recibió la funcionalidad, sabes que tres usuarios la recibieron y tres no, que es exactamente la estrategia de esta feature flag para la producción. A Becho le gustaría verificar la estrategia de feature flags en acción en el entorno de ensayo. Abre la aplicación en el entorno de ensayo e inicia sesión como MichaelArobaCFLRR.com. Comprueba que Michael obtiene la lista de productos en orden alfabético y nombre de producto. Cierra esta sesión e inicia sesión como MaryArobaCFL.RR.com. Confirma que Mary también recibe la funcionalidad en el entorno de ensayo. Recuerda que Michael y Mary estaban en la lista de usuarios que podían ver esta funcionalidad de ensayo. Cierra la sesión de Mary y, aún en el entorno de ensayo, inicia sesión como PeterArobaGmail.com a quien no se le debería servir la funcionalidad. Y así es, Peter no recibe una lista de productos en orden alfabético. A Becho le interesa ver cómo esta feature flag se implementa en la aplicación. Kitlava admite feature flags en varios lenguajes de programación, incluyendo Java, en el que está escrita esta aplicación. Va al directorio fuente de la aplicación y ve el archivo appcontroller.yava. Observa un bloque de declaraciones de importación para el proyecto de código abierto UNLIST, que es lo que usa Kitlab para implementar las feature flags. Encuentra la declaración de algunas variables, que son necesarias para implementar una feature flags en esta clase de Java. En el método constructor, ve la definición de tres de estas variables. Los valores UNLIST, la ID de la instancia y la URL se generan cuando se crean las feature flags y el nombre del entorno Kitlab es una variable del tiempo de ejecución. Se declara y se define un objeto de configuración UNLIST y luego se usa ese objeto configuración para crear una instancia de UNLIST predeterminada. Usarlas feature flags para la instancia de todas estas variables y objetos. Es tan simple como una declaración if-else. La declaración if verifica si se habilitaron las feature flags y si es así. Ejecuta la parte if que contiene la lista de productos en orden alfabético. Si feature flags no está habilitada, entonces ejecuta la parte else, que vuelve la lista de productos en el orden que se agregaron a la base de datos y no en orden alfabético. Instrumentar las feature flags proporciona una forma directa y sencilla de incorporarlas en el código. Las feature flags permiten probar las actualizaciones de tus aplicaciones de forma segura en producción, reducen el riesgo de interrupciones no programadas, se configuran e instrumentan fácilmente, son agnósticas al lenguaje y ayudan a estar al día y tener todo listo para auditorías. Gracias por ver y hasta la próxima.