Lanzamiento más rápido de aplicaciones JavaScript con Feature Flags

En primer lugar, al crear una nueva funcionalidad, probablemente creas una rama de características, lo cual significa que a medida que agregas código, también necesitas mantener tu rama actualizada con la rama principal. Esto puede volverse bastante tedioso y rápido al fusionar constantemente con la rama principal y resolver el conflicto.

El segundo problema surge al implementar, te encontrarás con todo tipo de preguntas sobre el proceso ¿ha sido aprobado por QA, se ha realizado toda la testing necesaria, ¿las etapas de prueba y producción son similares? ¿Estás seguro de que todo estará bien, etc.? Esto se debe a que poner algo en producción conlleva un alto riesgo. Por lo tanto, es necesario seguir muchos procesos para asegurarse de no afectar al negocio.

El siguiente problema surge cuando ocurre algo, entonces necesitas decidir qué hacer. ¿Haces un rollback? ¿Haces un roll forward? ¿Te tomas el tiempo para solucionar el error? ¿O no lo haces? Esto es un problema. Cuando hay un problema en producción, tiendes a entrar en pánico. Entonces, lo que el proceso tradicional te trae son tres problemas: tedio, burocracia y pánico. Las Feature Flags pueden aliviar o eliminar todos estos problemas, y voy a explicar eso ahora.

Tengo aquí una aplicación simple y voy a comenzar a agregarle funcionalidades. Ahora, si estoy haciendo una nueva funcionalidad con Feature Flags, lo primero que hago no es crear una nueva rama de características. En su lugar, creo una Feature Flag. En este caso, queremos agregar una funcionalidad que permita a las personas obtener una lista de emojis. Así que voy a llamar a mi Feature Flag Emoji y la crearé. Y agregaré algunas reglas aquí, que ahora guardaré. Y lo que esto dice ahora es que tengo una versión activada y una versión desactivada de esta Feature Flag, y de forma predeterminada está desactivada.

Ahora puedo ir a mi código. Y aquí, puedes ver que he agregado un componente React que crea la biblioteca de Feature Flags y la coloca en el contexto. Por lo tanto, puedo acceder a ella en cualquier lugar debajo de este componente en el árbol de componentes. Luego tengo mi componente real aquí donde voy a obtener la información sobre mi Feature Flag, específicamente, voy a obtener el tratamiento actual para esta Feature Flag. Si este tratamiento está activado, mostraré un enlace a la página de emojis y, de lo contrario, no lo mostraré. Lo último que haré aquí es agregar la página de emojis a mi código. Esta es una versión incompleta de la página de emojis. Pero está bien. Ahora puedo tomar mi cambio, solicitar una revisión, obtener la aprobación, fusionar directamente con la rama principal e implementar. Ahora podrías estar pensando, espera un momento, ¿qué estás haciendo implementando una versión incompleta de tu código en producción? Eso es bastante aterrador. Vamos a recibir errores de los clientes.

¿Estás loco? Pero puedo acceder a la aplicación, iniciar sesión y aún no veo un enlace a emojis. Esto se debe a que, por defecto, la Feature Flag está desactivada. He configurado mi código para que si el tratamiento está activado, se muestre esto. Por lo tanto, no muestro esto. Esto alivia al menos uno y medio de los problemas que mencionamos anteriormente.

Lo primero es que no necesito tener una rama de características. En su lugar, puedo hacer un cambio en una solicitud de extracción, solicitar una revisión, fusionar con la rama principal e implementar en producción. No tengo una rama duradera. Esto acelerará mi tiempo de desarrollo porque no estoy tratando de mantener dos ramas en paralelo.

Lo segundo es que, debido a que todos estos nuevos cambios están detrás de una Feature Flag, poner fragmentos en producción es de muy bajo riesgo. Necesitas mucho menos proceso, lo que significa que podrías ir a producción varias veces al día. Pero podrías estar pensando, bueno, esto es genial, estoy poniendo mis fragmentos en producción, ¿y qué? Bueno, parte de la respuesta es que ya lo hemos mencionado, hemos suavizado nuestro proceso. Pero hay un beneficio más allá de eso, porque mi proceso de lanzamiento ya no es todo o nada. Ahora puede ser altamente personalizado.

En este caso, voy a crear una regla que dice que cuando el ID de usuario actual sea David, es decir, yo, se muestre la versión activada. Así que puedo volver a la aplicación, actualizarla, iniciar sesión como yo y verás que obtengo los emojis. Ahora está incompleto, pero puedo verlo. En cambio, si inicio sesión como Emily, Emily no lo ve. Ahora he obtenido otra funcionalidad que ni siquiera sabía que me faltaba antes cuando estaba haciendo el desarrollo tradicional, que es poder hacer pruebas en producción. Con esto no me refiero a poner la funcionalidad y dejar que mis clientes la prueben. Lo que quiero decir es que puedo poner la funcionalidad en el entorno de producción y puedo probarla, mi equipo de control de calidad puede probarla, mi automatización puede probarla, mi equipo de ingeniería, mi empresa puede probarla. Puedo validar completamente esto en cada paso del proceso de desarrollo, cada solicitud de extracción que hago, alguien puede probarlo en producción y asegurarse de que esté bien, para que cuando finalmente lleguemos al punto de hacer el lanzamiento, ya hayamos estado probando esto durante semanas o meses, el tiempo que llevó construir esta funcionalidad.

Ahora que tengo esto, vamos a terminar esto. Ahora voy a tomar mi página de emojis y en realidad voy a agregar una página completa de emojis aquí y, nuevamente, implementar. ¿Correcto? Esto tomará un momento. Ahora puedes ver que mientras hago mi desarrollo, en realidad estoy construyendo una situación de mucha mayor calidad, porque constantemente estoy probando en producción, porque constantemente estoy poniendo cosas en producción y verificando incrementalmente que esté bien, es mucho más seguro. Así que cuando llego al punto de tener un lanzamiento, puedo ingresar aquí y probarlo, y diría que la funcionalidad se ve bien, puedo obtener algunos emojis. Ahora podemos decidir a quién lanzar esto más allá del equipo de ingeniería. Por ejemplo, puedo decidir, por defecto, dar esto al 50% de los usuarios y al 50% no. Así que voy a guardar este cambio, volver aquí.

Ahora, si inicio sesión como Emily, Emily no verá esto. Sin embargo, si inicio sesión como George, George sí lo verá. Así que el 50% de las personas lo ven, el 50% no. Genial. Ahora puedo realizar este proceso de implementación gradual. En lugar de hacerlo al 50%, puedo hacerlo al 5% o al 1%, y puedo obtener comentarios. ¿Estoy haciendo algo inesperado? ¿Estoy sobrecargando las bases de datos, por ejemplo? Y puedo detectarlo temprano en este proceso de lanzamiento.

No solo estoy acelerando el proceso de desarrollo con una mayor calidad al implementar constantemente y testing en producción, sino que también puedo aumentar la calidad al implementar gradualmente a mis usuarios. Genial. Ahora decidimos que hemos terminado. Listos para lanzarlo. Y luego recibimos una llamada del soporte al cliente diciendo, si haces ciertas cosas aquí, explota. Si estuviera siguiendo el proceso de desarrollo tradicional, ahora entraría en pánico, pero como estoy utilizando Feature Flags, no entro en pánico, simplemente digo, ok, tenemos un problema. Desactivemos esto. Simplemente voy a desactivar estas Feature Flags, lo que significa apagarlo inmediatamente. Vuelvo aquí. Si inicio sesión como George, no veo la nueva funcionalidad. Si inicio sesión como yo, no veo la nueva funcionalidad. Observa que solo tomó segundos apagar esto. En realidad, no tuve que hacer una implementación. Simplemente apagué la funcionalidad.

Esto a su vez alivia un tercer problema, que es el pánico. Con las Feature Flags, el gran problema en producción no es un pánico cultural. Simplemente deshaces la Feature Flag. Eso puede tomar segundos, y estás listo para luego continuar haciendo testing por tu cuenta. Gracias por escuchar. Espero que hayas encontrado esto útil. Prueba las Feature Flags. Cambiarán tu vida. ♪♪