Usando Feature Flags para Habilitar Pruebas en Producción

El siguiente problema que tuve fue que la preparación era muy lenta. Había un rendimiento realmente malo. Y muchas veces, cuando estás escribiendo pruebas en preparación, a menudo tienes que agregar esperas y pausas porque las cosas tardan más en cargarse. Por ejemplo, hacer clic en un botón, esperar 10 segundos a que suceda algo, realizar esta acción, esperar otros 10 segundos a que suceda algo. Tu usuario no va a esperar 10 segundos a que aparezca algo. Sabes, en tiempo tecnológico, eso es una locura. Entonces, ¿por qué hacerlo diferente en preparación?

A nadie le importa si la preparación está caída. Esta es otra razón, otra cosa con la que tuve que lidiar es que me asignaban probar diferentes problemas, probar diferentes tickets de corrección inmediata. Y estos eran simplemente correcciones críticas de errores que necesitaban ser lanzadas de inmediato a producción. Así que iniciaba sesión en preparación para probarlo, pero la preparación estaba caída. Así que tenía que contactar al chico de DevOps. Pero el chico de DevOps decía que tenía que abrir un ticket de TI y luego el ticket de TI tenía que ser escalado por mi gerente.

Mientras tanto, todo lo que estoy tratando de hacer es probar este ticket para nuestro producto. Y a nadie parece importarle. No es una prioridad para nadie. Nadie va a recibir una llamada en medio de la cena de Acción de Gracias porque la preparación está caída. Estaba tan cansada de lidiar con un entorno de preparación realmente malo y una experiencia de pruebas realmente mala y ser culpada cuando las cosas no funcionaban. Pensé que tenía que haber una mejor manera de probar software.

Mis usuarios finales no van a iniciar sesión en preparación para usar mi aplicación. Van a iniciar sesión en producción. Así que hice mucha investigación y averigüé qué están haciendo otras empresas. Esto es lo que aprendí. Lo primero es que es normal que las empresas usen entornos de preparación, especialmente las empresas que todavía siguen el modelo en cascada. Lo siguiente es que la mayoría de las empresas utilizan más de un entorno de preparación. Entonces, preparación, pre-producción, beta. La mayoría de las empresas tienen más de uno. Y grandes empresas como Google, Facebook, Netflix, Twitter, todas prueban en producción. Cuando leí eso, pensé, ¿qué es probar en producción? ¿Cómo es eso posible? ¿Qué quieres decir con probar en producción? Probar en producción significa probar tus funciones y el entorno en el que vivirán tus funciones, no utilizar un entorno ficticio como la preparación. Y pensé, wow, esto es perfecto. Esto resolverá todos mis problemas. También aprendí que probar en producción no significa que solo pruebes en producción. Aún utilizarás la preparación para datos relacionados con GDPR y SOX y problemas de privacidad, y pensé, esto es perfecto porque lo que no puedo probar en producción, simplemente lo probaré en preparación. Pero esos flujos de usuarios críticos, puedo ejecutarlos en producción. Pensé, esto es genial. ¿Cómo lo hago? ¿Cuáles son los pasos para llegar allí? Y la respuesta fueron las banderas de funciones. Una bandera de función es básicamente una forma de separar la implementación de código del lanzamiento de funciones. La idea aquí es implementar tu código en producción detrás de una bandera de función, probarlo en producción y luego lanzar la función con un clic de un botón tan pronto como esté libre de errores. ¿Cómo funciona? Esto es más o menos cómo se ve. Nuestros desarrolladores crearían una bandera de función desde la interfaz de usuario y luego apuntarían a todos nuestros compañeros internos. Lo que significa es que solo los usuarios que están dentro de la bandera de función mientras la bandera está desactivada podrán acceder a la función. Aquí puedes ver a los desarrolladores, probadores, diseñadores de productos, solo ellos tendrán acceso a esta nueva función mientras la bandera de función esté desactivada porque son los únicos a los que se dirige, estas personas a la derecha, estos usuarios finales reales, no pueden ver nada relacionado con la función porque no están dentro de la bandera de función.

Y luego, una vez que sabes que tu función está funcionando en producción, puedes activar la bandera sabiendo que tus funcionalidades están funcionando en producción al 100% y no has roto nada que ya existía. Y ahora tus usuarios están felices y están bailando porque tienen una función perfecta y pensé, esto es maravilloso. Este es un gran proceso. Como las banderas de funciones son geniales, pero ¿cómo las automatizas? No puedes probar manualmente cada función cada vez que lanzas una nueva versión. Y con las banderas de funciones, tienes esta complejidad adicional, ¿verdad? Entonces, ¿cómo lo automatizas? Y aquí hay dos opciones para la automatización. Y voy a explicar ambas.

La primera opción es dirigirse a los usuarios de prueba y automatizar los flujos con ellos. Lo que significa es que aquí, cuando te diriges a tus usuarios, también creas un automation robot, solo un usuario de prueba que se utilizará para ejecutar estas pruebas en producción. Así que cada vez que este usuario de prueba inicie sesión, tendrá acceso a esta nueva función. Y lo bueno de esta opción es que la prueba continuará ejecutándose incluso cuando activas la bandera de función, no tendrás que hacer ninguna configuración adicional. La única desventaja de este enfoque es que hay una mayor fragilidad, porque si alguien elimina a ese usuario de la lista de destinatarios o de la lista de permitidos en la bandera de función, tus pruebas fallarán. Así que solo tienes que asegurarte de que, si agregas a ese usuario, nadie lo eliminará de la configuración.

La siguiente opción es anular tus banderas de funciones y crear una abstracción personalizada de la bandera de función. Básicamente, esto significa que para cada función tienes tres pruebas. En la primera prueba, simulas que la bandera de función está activada. Y durante esta prueba, si recibes alguna solicitud preguntando si la bandera de función está activada, como si la prueba llega y pregunta, oye, ¿está activada la bandera de función?, dices que sí, y luego ejecutas la prueba de esa manera. Y luego, en la segunda prueba, simulas que la bandera de función está desactivada. Y si alguna solicitud llega desde la prueba preguntando si la bandera de función está activada, dices que no, y ejecutas la prueba de esa manera. Y luego, en la última prueba, quieres validar que puedes pasar por todo el flujo, independientemente de si la bandera está activada o desactivada. Y así, con este enfoque, eres muy explícito en la prueba, y la prueba se vuelve mucho más autoexplicativa y descriptiva. Así que cada vez que se ejecute una prueba utilizando banderas de funciones, el sistema en prueba simulará todas las variantes en el experimento. Y debido a que es simulado, se reducirá la complejidad de los diferentes escenarios, lo que significa pruebas más rápidas. Básicamente, lo que estás haciendo es establecer el estado de la bandera durante la duración de la prueba.

Y luego, cuando ejecutas tus pruebas en producción, quieres asegurarte de que tus pruebas solo interactúen con otras entidades de prueba, ¿verdad? Esto es algo que mucha gente teme, es decir, no quiero afectar a personas reales y usuarios reales en producción. Entonces, lo que haces es tener un sistema de marcado en el backend. Algo como 'is test user equals true', 'is test equals true', algo que identifique claramente todos tus objetos de prueba en producción y de esa manera separas los datos reales de los datos de prueba en tu panel de datos.

Entonces, digamos que estás usando Datadog o Looker o cualquier otra cosa. Cuando llegan tus datos, puedes crear un panel de control en Datadog o Looker o lo que estés usando, y puedes decir que todo, toda la lógica empresarial que llega y tiene usuarios de prueba estará en este grupo y todos los datos que llegan para usuarios reales estarán en este grupo. Y así es como puedes diferenciar entre datos reales y datos de prueba. Entonces, mis interesados van a ver los datos reales mientras que yo, como probador, y mi equipo de ingeniería, vamos a ver los datos de prueba y ver si se encontraron errores, ver qué necesita ser actualizado en las pruebas. Esos dos deben estar separados y así es como los separas.

Y lo bueno de esto es que las pruebas buscan elementos específicos con estos atributos de prueba específicos en producción. Entonces, si la prueba no encuentra ese elemento de prueba en producción, fallará y recibirás una alerta. Puede ser algo como una etiqueta ARIA o un atributo de datos, solo algo que puedas decir, esto es una cosa de prueba y esto es una cosa real. Sin embargo, hay excepciones. Si tu software está integrado con un tercero, puede ser complicado de probar. Puedes crear una cabecera única en la solicitud de API que envías al tercero y decir, 'oye, cualquier solicitud que recibas con esta cabecera es una prueba, y quiero que la trates de esta otra manera'. A veces tienes que hacer excepciones cuando estás probando en producción, tal vez enviar una confirmación por correo electrónico a un lugar específico en lugar del usuario final. A veces tienes que hacer esos cambios, pero vale la pena cuando estás probando en producción, cuando estás probando en un entorno en vivo.

Una pregunta que me hacen con frecuencia es cómo saber qué probar en producción. Hay dos lugares para comenzar. El primero es hablar con tu persona de producto, ir a tu gerente de producto y preguntarle, ¿cuáles son los flujos comerciales más importantes en nuestro producto? ¿Qué características nos brindan el mayor valor comercial? ¿Qué nos genera más ingresos? ¿Cuál es lo más importante para nuestro producto que debemos asegurarnos de que funcione todo el tiempo? El siguiente lugar es hablar con tu analista de datos, tu científico de datos y descubrir qué es lo que la gente hace más frecuentemente. Ten en cuenta que estas son dos cosas diferentes. ¿Qué es lo que la gente hace más frecuentemente y que, si se rompe, tendrás muchos problemas, tendrás muchos problemas en producción. Con estas dos listas, deberías tener una idea muy clara de por dónde empezar y qué flujos probar en producción.

Además de las banderas de características, hay otras dependencias que necesitas. Necesitarás un marco de automatización. No quieres ejecutar manualmente cada prueba. Quieres automatizar ese proceso, porque necesitas saber cuando algo falla y necesitas saberlo de inmediato. La velocidad de la automatización hace que eso sea muy fácil. Creo que eso es bastante obvio.

También necesitas un planificador de trabajos, y mencionaré algunas de mis recomendaciones. Necesitas un planificador de trabajos para ejecutar tus pruebas incrementalmente. Puedes tener dos conjuntos diferentes de pruebas. Tus pruebas más importantes se ejecutan cada hora, porque son críticas para el negocio, y luego puedes tener pruebas nocturnas que se ejecutan cada noche, porque son menos críticas.

Lo siguiente que necesitas es una herramienta de alerta para avisarte cuando tus pruebas fallan. Solo una herramienta de alerta que se pueda integrar con tu planificador de trabajos y que diga, oye, esta prueba falla, averigua qué está pasando. Estas son las herramientas recomendadas que he utilizado para las pruebas en producción. Para la segmentación de características, obviamente, recomiendo Split. Hay otras herramientas, y estoy feliz de hablar sobre ellas. Para un marco de automatización, mi favorito absoluto es Robot Framework. Y Robot es una biblioteca de automatización basada en palabras clave. Si no lo has probado, deberías hacerlo. Cypress es una biblioteca de JavaScript. Hay algunas otras para JavaScript que he utilizado, como Puppeteer. He tenido algunos problemas con ella en el pasado. Así que no recomendaría Puppeteer. Pero también está Protractor para aplicaciones Angular. Lo dije mal. Protractor para aplicaciones Angular. Pero obviamente, mi favorito es Robot. Funciona con la mayoría de las aplicaciones. Y luego, para tu planificador de trabajos, tienes Jenkins y CircleCI. Travis, Maven. No tengo preferencia entre ninguno de estos.

Para tus herramientas de alerta, tienes PagerDuty, Slack. Y nuevamente, puedes personalizarlas. Por ejemplo, para esas alertas críticas de negocio, puedes usar PagerDuty. Y para advertencias o cosas que se vean extrañas en la prueba, usa Slack.

Ok, hemos pasado por el cómo. Y este fue todo el proceso de testing y producción. Fuimos de la A a la Z, cómo configurarlo, cómo asegurarnos de que tus pruebas no interactúen con usuarios finales reales, cómo diferenciar esos datos, cómo configurarlo con banderas de características. Y pensé, esto tiene total sentido para mí. Pero si es tan simple, ¿por qué no todos lo hacen? ¿Por qué no todos hacen testing en producción? Y la verdad es que la gente tiene miedo. Las empresas no hacen pruebas en producción debido a este miedo y falta de confianza en sus sistemas. Y por la misma razón, se niegan a invertir en las herramientas y cambios de proceso que generarían esa confianza. Tienen demasiado miedo a los riesgos. Y hay algunas cosas que puedes hacer para mitigar los riesgos de testing en producción. La primera que mencionamos es usar banderas de características. Dirige a tus compañeros internos, haz pruebas con ellos. A esto también se le llama `comer tu propia comida`. Y luego activa la característica, sabiendo que tu característica funciona y no has roto nada que ya existía.

Lo siguiente que puedes hacer es un lanzamiento canario, que es simplemente una implementación porcentual. Y te permite lanzar tu característica a un pequeño subconjunto de usuarios antes de lanzarla a toda tu base de usuarios. Porque si algo sale mal, ¿preferirías que el 100% de tus usuarios encuentren el problema o solo el 1%? Lo siguiente que puedes hacer es comenzar con una prueba AA, lo que significa que brindas la misma experiencia a ambos conjuntos de usuarios dentro y fuera de la bandera de características y te aseguras de que los datos que llegan sean los mismos para ambos. Y lo que esto hará es aumentar tu confianza en el sistema de banderas de características. Y obviamente, comienza con algo pequeño, no empieces con tu flujo más complejo y decidas hacer pruebas en producción. Quieres comenzar con algo simple. Y el resultado de testing en producción es que puedes lanzar más rápido porque solo presionas un botón y tu característica se lanza. No tienes que pasar por todo el ciclo de lanzamiento porque tu código está listo, solo separas la implementación del lanzamiento. Y lo siguiente es que tienes una mayor velocidad de desarrollo. Tus desarrolladores pasan más tiempo creando nuevas características y menos tiempo solucionando errores. Y esto solo conduce a una mayor confianza y mayor felicidad del equipo. Y si no te he convencido de que esto es una buena idea, me gustaría que todos piensen en la última característica que su equipo implementó. ¿Está funcionando? ¿En este momento? ¿En producción? ¿Cómo lo sabes? Tus usuarios no te han informado nada, así que no lo sabes.

Probar en producción es la única forma de saber si tus características están funcionando en producción en este momento. Y muchas veces, cambiar la cultura de pruebas de tu empresa es la parte más difícil de este proceso. Así que superar ese miedo es una parte realmente importante de esto.

Lo que sugiero es comenzar a usar banderas de características, ve a split.io, haz clic en una cuenta de desarrollador gratuita y comienza a usar banderas de características para verificar si funciona para ti. Y en caso de que no hayas prestado atención en absoluto durante los últimos 20 minutos, quiero que te lleves dos cosas. La primera es que a nadie le importa si tus características funcionan en el entorno de preparación. Nos importa si funciona en producción. Y la única forma de saber si funciona en producción es probarlo en producción.

Así que muchas gracias por escuchar. Estoy aquí para responder preguntas. Puedes seguirme en Twitter, enviarme un correo electrónico. Y gracias. Muchas gracias por esa charla. Gracias por tomarte el tiempo para hablar con nosotros. Tenemos algunas preguntas de nuestra audiencia. ¿Estás listo para comenzar? Sí, estoy listo. Vamos a hacerlo. De acuerdo. Entonces RDM preguntó, Talia, ¿cómo tú y tu equipo manejan los errores críticos que afectan a todo el sitio o página? ¿Te refieres a después de todo el proceso de pruebas en producción y tenemos un error en producción? Entonces, si eso sucede y estás utilizando un lanzamiento canario, solo afectará a un pequeño porcentaje de tus usuarios. Pero lo más importante es que si usas banderas de características para probar esa característica en producción antes de tiempo, de todos modos no tendrás estos grandes problemas en producción. Podrás probar en el entorno en el que vivirá la característica. Entonces no tendrás esas sorpresas, no tendrás esos grandes problemas en producción. Y si los tienes, las banderas de características tienen algo llamado un interruptor de apagado, donde simplemente apagas la característica. Es como hacer clic en un botón y simplemente apagas la característica. No tienes que volver a implementar ningún código. No tienes que revertir nada en GitHub. Simplemente presionas un botón y la característica está apagada. Entonces el daño es muy, muy mínimo cuando usas banderas de características. Eso es genial.

Esa es una excelente manera de... Solo puedo pensar en todas las formas en que lo usaría, especialmente a veces... Sí, si tienes... La aplicación en la que trabajo, por ejemplo, tiene un montón de errores que aparecen para cuentas específicas que son muy difíciles de probar en local porque tendrías que probar... Replicar todas las condiciones. Sí. Eso parece súper útil.

Tukran preguntó, en mi experiencia, los entornos son tanto sobre la estructura de la empresa como sobre la tecnología. ¿Estás de acuerdo? Si es así, ¿qué tipo de cambios organizativos crees que serían necesarios para facilitar este enfoque?

Esa es una excelente pregunta. Esa es una pregunta realmente buena. En cuanto a la organización, siento que deben haber un par de cosas que deben estar en su lugar. Lo primero es que tu equipo necesita tener un marco de automatización sólido. Hablé un poco sobre esto en mi charla, pero necesitas tener una práctica sólida de pruebas con automatización implementada. No puedes simplemente comenzar a probar en producción y no tener ninguna automatización configurada. Eso es una gran parte de la cultura de pruebas de la empresa. Otra cosa es que las personas deben querer que esto suceda. Si tienes personas en tu equipo que están en contra de probar en producción y realmente no entienden el valor, esas dos cosas que sugerí al final, utiliza ejemplos de tu pasado. Pregúntales, ¿recuerdas cuando probamos esta cosa en preparación y funcionó perfectamente y luego, tan pronto como lo lanzamos en producción, hubo este problema? Piensa en momentos en los que tu entorno de preparación estaba caído y tuviste que probar algo y utiliza ejemplos de tu pasado. Y luego también, si no has ido a split.io, puedes crear una cuenta de desarrollador gratuita y comenzar a usar nuestros SDK. Es súper útil. También tengo un montón de tutoriales allí. Así que sí, ahí es donde comenzaría. Pero también diré, siempre habrá personas que dirán que probar en producción nunca funcionará y que debes usar preparación y generalmente son esas personas mayores en las empresas que han estado allí durante 20 años y no les gusta mucho el cambio. Así que ignora a esas pocas personas. En su mayor parte, esta es una práctica realmente innovadora y si se hace correctamente, los beneficios son simplemente infinitos. Sí, seguro. Sí, siempre es difícil impulsar ese cambio organizativo, cambiar la mentalidad de las personas, especialmente si han sido perjudicadas por lo que estás tratando de hacer. Pero probar en producción es muy diferente a lo que era hace años. Sí, y es porque tenemos las herramientas que nos permiten hacerlo de manera segura. No estamos simplemente lanzando código en producción y diciendo, a ver qué pasa.

Es muy seguro, está muy planificado. Sí, sí, sí, ahora puedes hacerlo.

Tom pregunta, ¿eliminas las banderas después de que una característica se haya lanzado y esté funcionando? Sí. Sí, de hecho, escribí una publicación completa en el blog sobre cuándo desactivar una bandera de características y cuándo degradar una bandera de características. Básicamente, dependiendo del caso de uso para el que estés utilizando una bandera, es cuando sabes cuándo eliminar la bandera. Pero para pruebas y producción, una vez que una característica se haya lanzado por completo y se haya lanzado al 100% de tu población y sabes que funciona, entonces puedes eliminar la bandera. Y no quieres tener banderas de características antiguas en tu código base. Claro, sí, por supuesto.

William preguntó, esto creo que es realmente interesante. Trabajo con muchas bibliotecas que tenemos que actualizar en diferentes productos. La pregunta de William me llamó la atención. Preguntó cómo gestionas las dependencias entre las banderas de características. Básicamente, cuando estás dirigiendo tus bots de automatización dentro de tus banderas de características, simplemente te aseguras de dirigir el mismo bot en las diferentes banderas de características que necesitas. Entonces, digamos que tienes un flujo de usuario uno y un flujo de usuario dos y son dos características diferentes, pero dependen una de la otra para funcionar. Entonces, lo que haría es dirigir mi usuario de prueba en ambas banderas de características para que cuando ese usuario ejecute la automatización para ambas banderas, cuando se ejecuten esas pruebas, sabrás si algo falla porque es el mismo usuario que está ejecutando las tareas. Genial, eso es genial.

Yousef V, o Yousef, dijo, gran charla. Estoy de acuerdo, fue genial. ¿Esta práctica suele ir acompañada del desarrollo basado en tronco? Sí, sí, sí, lo está. De acuerdo, Thomas preguntó, ahora estamos evaluando servicios de banderas de características, y estamos buscando uno que admita múltiples dimensiones para describir a los usuarios. Dimensiones entre paréntesis, creo que es. Por ejemplo, nos gustaría cambiar las banderas para usuarios específicos en todos los niveles gratuitos versus clientes de nivel profesional o incluso a nivel global para todos los usuarios. ¿SPLIT admite esto? Lo siento, ¿puedes repetir eso? Sí, fue una pregunta larga. Entonces, parece que Thomas está evaluando servicios de banderas de características, y están buscando uno que admita múltiples dimensiones para describir a los usuarios. Por ejemplo, nos gustaría cambiar las banderas para usuarios específicos en todos los niveles gratuitos versus clientes de nivel profesional o incluso a nivel global para todos los usuarios. Y están preguntando si SPLIT admite esto. Sí, con SPLIT, lo que puedes hacer es segmentar tu base de usuarios en diferentes categorías. Puedes decir usuarios gratuitos en un segmento, usuarios pagados en otro segmento, y luego puedes agregar configuraciones dinámicas para decir que para estos usuarios quiero mostrar esto y para este usuario quiero mostrar esto. Y puedes configurarlo como quieras. Mientras crees los diferentes segmentos de usuarios que necesitas, eso es totalmente posible en SPLIT. Realmente sugiero que si no has iniciado sesión en SPLIT.io, crees una cuenta gratuita. Tenemos tantos SDK diferentes que puedes usar y estoy feliz de responder preguntas si tienen preguntas sobre diferentes tutoriales. Eso es genial. Muchas gracias Talia por unirte y gracias por esa increíble charla. Gracias. Adiós. Adiós. Adiós, adiós. Adiós.