Usando Feature Flags para Habilitar Pruebas en Producción

Rate this content
Bookmark

¿Cómo sabes si tu función está funcionando perfectamente en producción? Si algo se rompe en producción, ¿cómo lo sabrás? ¿Esperarás a que un usuario te lo informe? ¿Qué haces cuando los resultados de tus pruebas de preparación no reflejan el comportamiento actual de producción? ¡Para probar de manera proactiva en lugar de reactiva, prueba en producción! Tendrás una mayor precisión en los resultados de las pruebas, tus pruebas se ejecutarán más rápido debido a la eliminación de datos incorrectos y tendrás más confianza antes de los lanzamientos. Esto se puede lograr a través de la implementación de flags de características, lanzamientos canarios, configuración de un pipeline de CI/CD adecuado y limpieza de datos. Saldrás de esta charla con estrategias para mitigar riesgos, mejorar tu comprensión de los pasos necesarios y cambiar la cultura de pruebas de tu empresa, para poder brindar la mejor experiencia posible a tus usuarios. Al final del día, no nos importa si tus funciones funcionan en preparación, nos importa si funcionan en producción.

29 min
02 Jul, 2021

Video Summary and Transcription

La charla de hoy trata sobre habilitar pruebas en producción, incluyendo los desafíos con los entornos de preparación, el uso de flags de características para pruebas y la automatización de las pruebas de flags de características. También se aborda la ejecución de pruebas en producción asegurando que no haya impacto en los usuarios reales, determinando qué probar en producción, herramientas y dependencias recomendadas, y mitigando riesgos. Se enfatiza la importancia de las pruebas en producción y el cambio de la cultura de pruebas, junto con la necesidad de un marco de automatización sólido y la gestión de dependencias de flags de características.

Available in English

1. Habilitar pruebas en producción

Short description:

Hola a todos. Hoy discutiremos cómo habilitar pruebas en producción, incluyendo qué es, cómo configurarlo y los problemas comunes. Como ex ingeniero de pruebas, me enfrenté a desafíos con los entornos de preparación que diferían de la producción. La falta de coincidencia de datos y la deriva de configuración causaron problemas, y la preparación fue lenta y con un rendimiento deficiente. El tiempo de inactividad de preparación obstaculizó las correcciones críticas de errores. Vamos a explorar estos problemas y su impacto en las pruebas.

y mi correo electrónico, en caso de que tengan preguntas más adelante. Pero un poco sobre mí. Soy una defensora del desarrollo en Split. Y solía ser ingeniera de pruebas, y trabajé en QA y automation y testing durante un tiempo antes de unirme a Split. Y ser ingeniera de pruebas fue realmente difícil para mí, porque la mayoría de los problemas que tuve giraban en torno a la preparación y el uso de este entorno ficticio, y la preparación no es lo mismo que la producción. Así que tenía muchos problemas, y estos son algunos de los problemas con los que lidié y estoy segura de que muchos de ustedes también han lidiado. Si han trabajado con algún tipo de entorno de pruebas, algún tipo de entorno de QA, cualquier cosa que no sea producción, estos son algunos de los aspectos que dificultaron mucho mi trabajo. Así que el primer problema fue la falta de coincidencia de data. Entonces, los data en la preparación no coinciden con la producción, lo que significa que los resultados de las pruebas no siempre coinciden. Así que solía trabajar muy duro para asegurarme de probar cada requisito del producto, y revisaba la documentación con el propietario del producto, y trabajaba con mis desarrolladores para solucionar todos los errores, asegurarme de que mis pruebas de extremo a extremo pasaran, y luego firmaba la función, y tan pronto como se lanzaba a producción, había un error. Es una sensación horrible cuando hay tanta presión sobre ti para asegurarte de que tu función funcione en un entorno ficticio. Y luego, lo siguiente con la falta de coincidencia de data que me sucedió fue algo llamado deriva de configuración, y lo que esto significa es que digamos que te llaman una noche porque hay un incidente en tu aplicación, y miras los registros e identificas los problemas, pero para solucionarlo, debes actualizar una configuración específica en producción, así que haces el cambio en producción y vuelves a dormir. Y aunque solucionaste el problema, acabas de crear una brecha aún mayor entre tus entornos de preparación y producción. Esta brecha se llama deriva de configuración, y muchas veces, los entornos de preparación no son iguales a la producción debido a los cambios realizados durante la gestión de incidentes, lo que solo agrega una mayor deriva de configuración. Y sentí que, ¿cuál es el punto de testing en preparación si no me va a dar los mismos resultados que la 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.

2. Testing in Production and Feature Flags

Short description:

Mientras tanto, todo lo que estoy tratando de hacer es probar este ticket para nuestro producto. Mis usuarios finales no van a iniciar sesión en preparación para usar mi aplicación. Así que hice mucha investigación y averigüé qué están haciendo otras empresas. Lo primero es que es normal que las empresas usen entornos de preparación. La mayoría de las empresas utilizan más de un entorno de preparación. Grandes empresas como Google, Facebook, Netflix, Twitter, todas prueban en producción. Probar en producción significa probar tus funciones y el entorno en el que vivirán tus funciones. 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. 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. ¿Cómo funciona? Nuestros desarrolladores crearían una bandera de función desde la interfaz de usuario y luego apuntarían a todos nuestros compañeros internos.

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.

3. Automatización de las pruebas de las banderas de funciones

Short description:

Mientras la bandera de función está desactivada, se prueban todas las funcionalidades, el diseño y los requisitos. Los errores no afectan a los usuarios finales ya que no están dirigidos a ellos. Si se encuentra un error, se envía de vuelta al equipo de desarrollo para su corrección y nueva prueba. Una vez que la función está funcionando en producción, se puede activar la bandera, asegurando que las funcionalidades existentes no se rompan. La automatización de las pruebas de las banderas de funciones tiene dos opciones: dirigirse a los usuarios de prueba y automatizar los flujos o anular las banderas de funciones con abstracciones personalizadas. Ambas opciones tienen sus ventajas y desventajas, pero proporcionan pruebas más rápidas y autoexplicativas.

Así que pruebas todas tus funcionalidades, pruebas tu design, pasas por todos los requisitos, te aseguras de que todo funcione. Si hay un error, no afecta a tus usuarios finales porque, de nuevo, no tienen acceso a él. No están dirigidos a ellos. Así que cuando hay un error, lo envías de vuelta a tu equipo de desarrollo. Lo corrigen. Lo pruebas de nuevo y ese proceso continuará hasta que tengas una función sin errores en producció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.

4. Ejecución de pruebas en producción

Short description:

Al ejecutar pruebas en producción, es importante asegurarse de que solo interactúen con entidades de prueba y no afecten a los usuarios reales. Esto se puede lograr mediante un sistema de marcado en el backend que separa los datos reales de los datos de prueba. Mediante el uso de atributos de prueba específicos, las pruebas pueden identificar y diferenciar entre datos de prueba y datos reales en producción. Sin embargo, puede haber excepciones al probar software integrado con terceros, lo que requiere un manejo especial. A pesar de estos desafíos, las pruebas en producción son valiosas para identificar errores y mejorar la calidad del software.

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.

5. Determinar qué probar en producción

Short description:

Para determinar qué probar en producción, consulta a tu gerente de producto para identificar los flujos comerciales más importantes y las características que generan ingresos. Además, trabaja con tu analista de datos para comprender el comportamiento del usuario y priorizar las pruebas en áreas críticas. Estos conocimientos te guiarán para seleccionar qué flujos probar en producción.

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.

6. Dependencies and Recommended Tools

Short description:

Además de las banderas de características, necesitarás un marco de automatización para automatizar el proceso de prueba. Un planificador de trabajos es necesario para ejecutar pruebas incrementalmente, con pruebas críticas que se ejecutan cada hora y pruebas nocturnas para las menos críticas. Una herramienta de alerta integrada con el planificador de trabajos puede notificarte sobre fallas en las pruebas. Las herramientas recomendadas incluyen Split para la segmentación de características y Robot Framework para la automatización. También hay otras opciones como Cypress y Protractor para aplicaciones Angular. Los planificadores de trabajos como Jenkins, CircleCI, Travis y Maven también se utilizan comúnmente.

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.

7. Mitigating Risks of Testing in Production

Short description:

Para las herramientas de alerta, puedes usar PagerDuty para alertas críticas y Slack para advertencias o anomalías. Las pruebas en producción no son comunes debido al miedo y la falta de confianza en los sistemas. Mitiga los riesgos utilizando banderas de características, realizando lanzamientos canarios y comenzando con pruebas AA. Las pruebas en producción permiten lanzamientos más rápidos, mayor velocidad de desarrollo y mayor confianza del equipo. Considera la última característica que tu equipo implementó y pregúntate si está funcionando en producción sin informes de usuarios.

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.

8. Testing in Production and Dealing with Bugs

Short description:

Probar en producción es la única forma de saber si tus características están funcionando en producción en este momento. Cambiar la cultura de pruebas de tu empresa es la parte más difícil. Comienza a usar banderas de características y verifica si funciona para ti. A nadie le importa si tus características funcionan en el entorno de preparación. Nos importa si funciona en producción. Gracias por escuchar. Estoy aquí para responder preguntas. ¿Cómo manejas los errores críticos? Si usas banderas de características para probar las características en producción antes de tiempo, no tendrás grandes problemas en producción. Las banderas de características tienen un interruptor de apagado para desactivar fácilmente las características.

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.

9. Testing in Production and Organizational Changes

Short description:

Probar en producción requiere un marco de automatización sólido y una cultura de pruebas. Utiliza ejemplos de experiencias pasadas para mostrar el valor. Ignora a aquellos que se resisten al cambio. Probar en producción es diferente ahora con las herramientas disponibles.

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.

10. Removing Flags and Managing Dependencies

Short description:

Cuándo eliminar una bandera de características depende del caso de uso. Para pruebas y producción, una vez que una característica se haya lanzado por completo y esté funcionando, se puede eliminar la bandera. La gestión de dependencias entre banderas de características implica dirigirse al mismo usuario en diferentes banderas para garantizar que las características interdependientes funcionen correctamente. El uso de banderas de características es comúnmente utilizado en conjunto con el desarrollo basado en tronco. SPLIT admite múltiples dimensiones para describir a los usuarios, lo que permite realizar cambios específicos en las banderas en diferentes segmentos de usuarios.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Top Content
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Top Content
Featured Video
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.
Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Top Content
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Top Content
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
TestJS Summit 2021TestJS Summit 2021
31 min
Test Effective Development
Top Content
Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!But how do we do that?Are the "unit" and "integration" terminology serves us right?Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!It’s time to go DEEPER!

Workshops on related topic

React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Top Content
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
TestJS Summit 2023TestJS Summit 2023
48 min
API Testing with Postman Workshop
WorkshopFree
In the ever-evolving landscape of software development, ensuring the reliability and functionality of APIs has become paramount. "API Testing with Postman" is a comprehensive workshop designed to equip participants with the knowledge and skills needed to excel in API testing using Postman, a powerful tool widely adopted by professionals in the field. This workshop delves into the fundamentals of API testing, progresses to advanced testing techniques, and explores automation, performance testing, and multi-protocol support, providing attendees with a holistic understanding of API testing with Postman.
1. Welcome to Postman- Explaining the Postman User Interface (UI)2. Workspace and Collections Collaboration- Understanding Workspaces and their role in collaboration- Exploring the concept of Collections for organizing and executing API requests3. Introduction to API Testing- Covering the basics of API testing and its significance4. Variable Management- Managing environment, global, and collection variables- Utilizing scripting snippets for dynamic data5. Building Testing Workflows- Creating effective testing workflows for comprehensive testing- Utilizing the Collection Runner for test execution- Introduction to Postbot for automated testing6. Advanced Testing- Contract Testing for ensuring API contracts- Using Mock Servers for effective testing- Maximizing productivity with Collection/Workspace templates- Integration Testing and Regression Testing strategies7. Automation with Postman- Leveraging the Postman CLI for automation- Scheduled Runs for regular testing- Integrating Postman into CI/CD pipelines8. Performance Testing- Demonstrating performance testing capabilities (showing the desktop client)- Synchronizing tests with VS Code for streamlined development9. Exploring Advanced Features - Working with Multiple Protocols: GraphQL, gRPC, and more
Join us for this workshop to unlock the full potential of Postman for API testing, streamline your testing processes, and enhance the quality and reliability of your software. Whether you're a beginner or an experienced tester, this workshop will equip you with the skills needed to excel in API testing with Postman.
Node Congress 2023Node Congress 2023
109 min
Node.js Masterclass
Workshop
Have you ever struggled with designing and structuring your Node.js applications? Building applications that are well organised, testable and extendable is not always easy. It can often turn out to be a lot more complicated than you expect it to be. In this live event Matteo will show you how he builds Node.js applications from scratch. You’ll learn how he approaches application design, and the philosophies that he applies to create modular, maintainable and effective applications.

Level: intermediate
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.