1. Introducción a la Monitorización y Pruebas
Soy Carly Richmond, una Defensora Principal del Desarrollador en Elastic. Hoy, hablaré sobre la relación entre la monitorización sintética y las pruebas de extremo a extremo. Utilizar diferentes herramientas para esto es duplicar esfuerzos. Exploraremos un ejemplo de cómo utilizar Playwright, GitHub Actions y Elastic Synthetics para desplazar las monitorizaciones hacia la izquierda como código y fomentar la colaboración.
¡Hola, DevOpsJS! Es genial verlos a todos hoy. Mi nombre es Carly Richmond. Soy una Defensora Principal del Desarrollador en Elastic. Soy una ingeniera de front-end. Y también, soy un poco fanática de las pruebas. Y hoy estoy aquí para hablarles sobre la monitorización, lo cual probablemente esperaban en una conferencia de DevOps, pero también estoy aquí para hablarles sobre las pruebas, lo cual podría haber sido una sorpresa. Estoy aquí para argumentar que la monitorización sintética y las pruebas de extremo a extremo son dos caras de la misma moneda. Son constructos muy similares. Y de hecho, utilizar diferentes herramientas para esto es duplicar esfuerzos en el lado del desarrollo y las operaciones. Vamos a ver un ejemplo de cómo se puede hacer esto para aplicaciones web en JavaScript, utilizando Playwright para JavaScript y TypeScript, GitHub Actions, y también un proveedor de observabilidad que en este caso es Elastic Synthetics, para intentar desplazar nuestras monitorizaciones hacia la izquierda como código.
2. Desafíos de la Colaboración y el Desplazamiento a la Izquierda
En mi experiencia como desarrollador, me he enfrentado a desafíos debido a la falta de colaboración entre desarrolladores, soporte y probadores. El desplazamiento a la izquierda, aunque es una gran idea en teoría, a menudo conduce a una experiencia fragmentada. Los silos existentes, las barreras culturales y las diferentes prioridades dificultan la colaboración. La calidad se convierte en un pensamiento posterior y el uso de diferentes conjuntos de herramientas para los mismos objetivos crea confusión.
desplazamiento a la izquierda como
code y tratar de colaborar más juntos. Así que primero, necesito establecer el escenario de mi experiencia porque esto es algo que al comienzo de mi carrera, realmente desearía haber tenido. Habría resuelto varios problemas con los que luché. Así que mi primer trabajo como desarrollador, que fue en 2011, fue un poco raro porque trabajé en un equipo pequeño. Tuvimos que hacer de todo. Éramos desarrolladores, éramos analistas de soporte, lidiábamos con situaciones de interrupción, pruebas de aceptación de usuarios, recopilación de requisitos. Básicamente, hice de todo y llevé muchas gorras diferentes. Y luego, fue solo cuando delegamos algunas pruebas y algo de soporte donde pude trabajar con personas y aprender algunas mejores prácticas en lugar de seguir adelante como pude. Pero luego, cuando cambié de puesto, descubrí que esa experiencia previa es muy, muy rara. De hecho, la situación normal, que todavía escucho de muchos ingenieros de
DevOps y SRE, es más como un juego de Rock'em Sock'em Robots cuando se trata de desarrolladores y soporte, a veces casi en desacuerdo con ideas conflictivas. Y muy a menudo hay probadores en segundo plano, a menos que hayamos terminado con la situación en la que los desarrolladores son responsables de sus propias pruebas y validaciones. Ahora, el desplazamiento a la izquierda no es algo nuevo. Y cuando escuché por primera vez sobre esto, pensé que era una gran idea. Esto llevará a tal vez un poco más de armonía en esa situación. Tal vez, ya sabes, con la aparición de prácticas comunes, podemos trabajar juntos. Yo y otros desarrolladores podemos aprender más sobre cómo construir aplicaciones más mantenibles. Sabes, tal vez todo será genial. Y en cambio, he visto algo un poco diferente suceder donde en realidad, en algunos aspectos, tenemos todas estas grandes disciplinas adicionales. Si piensas en SRE, ingenieros de
DevOps, allí tenemos ingenieros rápidos, todas estas personas que pueden profundizar en temas y mostrar experiencia. Pero aún así, no necesariamente colaboramos bien juntos. Y esto todavía puede llevar a una experiencia muy fragmentada. Y hay varias razones para eso. La primera es que especialmente en organizaciones grandes, esos silos existentes aún persisten. Y de hecho,
DevOps a menudo se adopta a partir de una función de gestión de producción existente, lo que significa que no se alinea realmente con los desarrolladores porque todavía tienen esas especies de mezclas culturales y barreras en su lugar. Nuestra empatía no es muy buena. No somos muy buenos tratando de entender el otro lado de eso, porque las actividades de SRE, actividades de ingenieros de
ML, actividades de desarrolladores, estas cosas son sorprendentemente diferentes, hasta el punto en que incluso las prioridades que tenemos como equipos son diferentes y pueden ser difíciles de alinear juntas también. A veces, la calidad es un poco descuidada. Los desarrolladores y la idea de desplazarse a la izquierda significa que hemos tenido que aprender todo tipo de cosas locas sobre seguridad, mejores prácticas, manejo de errores, diagnóstico de monitoreo. Y en realidad, necesitamos más ayuda porque de lo contrario solo cubrimos las grietas. Pero el mayor problema, para ser honesto, es que estamos usando conjuntos de herramientas muy diferentes, lo cual a veces tiene sentido para el rol que estamos desempeñando. Pero cuando estamos usando los
3. Desafíos de Diferentes Herramientas para las Pruebas
En mi último trabajo de ingeniería, nos enfrentamos a desafíos debido al uso de diferentes herramientas para las pruebas de extremo a extremo y el monitoreo sintético. Esto llevó a diferentes interpretaciones de cómo debería funcionar el sistema y resultó en esfuerzos duplicados. Para abordar esto, necesitamos unirnos y utilizar un conjunto común de herramientas, desplazando los monitores a la izquierda y utilizándolos como código. Hoy les mostraré un ejemplo de cómo lograr esto utilizando Playwright para JavaScript y Elastic Synthetics para la observabilidad. También discutiremos el flujo tradicional, desde el desarrollo local hasta la ejecución de monitores en el pipeline de CI y la implementación en producción. El ejemplo que cubriremos es el flujo de inicio de sesión, que incluye la entrada de texto manual y agregar elementos al carrito.
mismas diferentes herramientas para lograr los mismos objetivos, ya no tiene mucho sentido. Y en mi último trabajo de ingeniería, lo que realmente me sorprendió fue el hecho de que estábamos usando diferentes herramientas para las pruebas de extremo a extremo y el monitoreo sintético. Y no podía entender por qué. Así que antes de entrar en la idea de lo similares que son, primero establezcamos el escenario para aquellos que son nuevos en estos términos. Las pruebas de extremo a extremo se refieren a la capacidad de utilizar un
framework de automatización, como Playwright, como estamos usando hoy, o tal vez
Cypress, o en una vida anterior cuando estaba construyendo aplicaciones
Angular, Protractor, que afortunadamente ya no está aquí, para tratar de automatizar el flujo de trabajo del usuario, esas operaciones que realizan para interactuar con sus aplicaciones web, como clics e ingreso de texto, con el fin de validar que lo que hemos construido corresponde a esa especificación y funcionará como ellos lo pretendieron. El monitoreo sintético es básicamente cuando, en un horario periódico, ejecutamos alguna forma de script para probar la disponibilidad de nuestra aplicación cada pocos minutos o unas pocas horas potencialmente. Podríamos pensar que es algo simple, como hacer ping a un punto de conexión HTTP solo para ver si todavía está activo, pero con la aparición de monitores con guiones en los últimos años, eso también puede significar realizar recorridos de usuario, automatizando los mismos pasos que realizan para asegurarse de que un usuario realmente pueda realizar ese flujo de trabajo en ese momento en el sistema. Entonces, estamos automatizando lo mismo. Estamos automatizando el flujo de trabajo del usuario, los clics, y debido a que los estamos construyendo con diferentes herramientas, mientras yo estaba construyendo en
Cypress en mi último rol de desarrollador, tenía colegas que eran SRE que estaban escribiendo estos monitores en Selenium utilizando Apica como envoltorio. Y simplemente no entiendo porque eso lleva a diferentes interpretaciones sobre cómo debería funcionar el sistema porque los flujos de trabajo no siempre funcionan de la misma manera. Y también está llevando a un esfuerzo duplicado fundamentalmente. Así que creo que necesitamos cambiar esa noción. Creo que necesitamos unirnos y tratar de utilizar un conjunto común de herramientas y básicamente desplazar los monitores a la izquierda para que los usemos como código, lo que luego puede funcionar como una especificación de prueba de extremo a extremo. Y vamos a mostrar un ejemplo de cómo hacerlo hoy. Voy a usar Playwright para
JavaScript, que es una biblioteca de pruebas de extremo a extremo mantenida por Microsoft. Y tengo ejemplos en
TypeScript aquí también. Tenemos acciones de GitHub para que podamos ejecutar estas pruebas en
CI como parte de cualquier tipo de verificación previa a la implementación o integración. Y luego necesitamos un proveedor de observabilidad porque estamos monitoreando nuestra aplicación. Y en este caso, vamos a utilizar Elastic Synthetics para envolver nuestra prueba de Playwright y permitir que capture la actividad del monitor y ejecutarlo según un horario en producción. Todos los códigos y las diapositivas que voy a mostrar hoy están disponibles en ese código QR que pueden ver en la esquina y no se preocupen. Volverá al final. Pero antes de sumergirnos en el ejemplo, vamos a tener claro cómo encajan estos elementos en términos de un flujo tradicional.
Tomemos el ejemplo de los desarrolladores que trabajan en una nueva función. Lo que harán es construir la función junto con la escritura de un archivo de recorrido, un monitor que pueden usar como una prueba de extremo a extremo utilizando Playwright. Y ejecutarán eso como parte de su práctica de desarrollo local con suerte participando en el desarrollo impulsado por pruebas. Luego, enviarán sus cambios, el monitor y los cambios de código al control de origen y pasarán por cualquier revisión y verificaciones ejecutando estos monitores como una prueba de extremo a extremo dentro del pipeline de CI. Luego, cuando llegamos a implementar nuestra aplicación para mantener nuestros monitores sincronizados con la aplicación de producción, necesitamos poder enviarlos a donde deben ejecutarse utilizando la autenticación de clave de API, que luego se ejecutará en su propia ubicación o dentro de la ubicación proporcionada por el proveedor de observabilidad. Y luego, en este caso, persistir los resultados en Elasticsearch y luego poder ver los resultados en un panel brillante. El ejemplo que voy a cubrir hoy es el flujo de inicio de sesión que están viendo parpadear frente a ustedes en este momento. Un simple ingreso de texto manual para ingresar nombre de usuario y contraseña para ir a una pantalla de pedido y luego
4. Conversión de Prueba de Playwright en Monitor
Para convertir la prueba de Playwright en un monitor, comenzamos verificando el formulario de inicio de sesión y obteniendo el botón. Agregamos las credenciales a los cuadros de texto de entrada y verificamos sus valores. Luego verificamos que el botón de envío esté habilitado y nos aseguramos de navegar a la página esperada.
comenzamos a agregar elementos al carrito. Entonces, primero, necesitamos esa prueba de Playwright que luego podemos convertir más tarde en un monitor. Aquí verán que tengo una prueba muy básica frente a mí aquí que básicamente está pasando por comenzar desde la línea cuatro. Vamos a la página de inicio de sesión. Estamos obteniendo el formulario de inicio de sesión utilizando el atributo de ID de prueba
data como parte de este selector. Esto es lo que recomendaría como práctica porque lo último que quieres hacer, lo cual he hecho en el pasado, es acoplar esto a clases
CSS que también estás usando para estilizar o a estructuras
CSS complejas con padres anidados, lo que significa que tan pronto como muevas algo o cambies algo en la vista, romperás todas tus pruebas. Así que trata de evitar hacer eso. Verificamos que el formulario de inicio de sesión esté definido, luego vamos y obtenemos el botón, verificamos que esté deshabilitado, agregamos nuestras credenciales. Esta es solo una prueba que tengo. Si quieres reutilizar tus credenciales, Playwright tiene la opción de hacerlo persistiendo sus credenciales en un archivo JSON. Consulta la documentación de autenticación para eso. Pero las estamos agregando a los cuadros de texto de entrada para el nombre de usuario, verificando que el valor del cuadro de texto sea realmente lo que agregamos. Lo mismo para la contraseña. Luego verificamos que ahora podemos enviar el botón, y luego nos aseguramos de que estemos navegando a la página como esperamos.
5. Envolver Prueba como Monitor
Para envolver la prueba como un monitor, crea un nuevo proyecto de Synthetics. Utiliza el asistente de inicio para generar un proyecto de muestra con código esqueleto. El proyecto incluye monitores de ejemplo en la carpeta de recorridos. La configuración del proyecto especifica parámetros, como la URL y las variables de entorno. También se configuran las opciones de Playwright y los ajustes del monitor. Transforma la prueba en un recorrido dividiéndola en pasos más pequeños utilizando las construcciones de recorrido y paso.
Lo que debemos hacer a continuación es envolver esto como un monitor. Y la forma de hacerlo es crear un nuevo proyecto de Synthetics. Así que tendremos una instalación global, que puedes ver aquí arriba, luego utiliza el asistente de inicio como parte del tercer comando para generar ese proyecto de muestra, que generará el código esqueleto. Así que verás, tienes la carpeta de recorridos. Estos son monitores de ejemplo que vamos a ejecutar como pruebas para mostrarte cómo empezar. Luego tienes monitores de latido ligero. Así que si quieres hacer cosas como pings, puedes mantenerlos todos en el mismo repositorio que el code, no vamos a cubrir eso hoy. Y luego tienes la configuración del proyecto con todas tus configuraciones. Si pasamos a eso, verás aquí, este es el archivo de configuración. Estoy especificando parámetros. Así que tengo la URL, puedes ver que es local host. Esto es lo que haría ping en un escenario predeterminado. Pero si nos desplazamos hasta la línea 30, verás que en realidad cuando el entorno es producción, cambio la URL para que coincida. Y eso significa que no tenemos la situación en la que el monitor fallará cuando lo enviemos porque está intentando acceder a una aplicación que se ejecuta localmente y no existe. También estoy pasando el nombre de usuario y la contraseña para poder utilizar los mismos valores recogidos del entorno en el monitor, así como en NCI y en el desarrollo local. Así que usarías un archivo de entorno localmente para gestionarlo. Luego tienes tus opciones de Playwright, según la documentación de Playwright, cualquier configuración específica que necesites. Y luego la configuración del monitor para todos los monitores del proyecto, a menos que se indique lo contrario. Así que estamos estableciendo el horario en 10 minutos. Lo tenemos ejecutando en una ubicación del Reino Unido, y luego no he configurado ninguna ubicación yo mismo. Esta es una ubicación elástica en el Reino Unido. Así que eso está bien. Si configuras una ubicación privada, se mostrará aquí. Y luego tengo la configuración del proyecto. Así que necesito saber dónde está mi implementación. Estos son los detalles de implementación en la cloud. Esto es un punto hacia una versión local en ejecución, si es eso lo que tenías, el espacio de cabana y luego el ID.
Ahora debemos transformar esa prueba que teníamos antes en un recorrido, lo que significa que queremos intentar dividirla en pasos más pequeños, lo que nos permite obtener información más detallada sobre lo que está fallando. Lo primero que notarás, si miras en la parte superior, es
6. Running and Deploying the Monitor
Pasa el objeto de página, los parámetros y la configuración al recorrido. Anula la configuración del monitor si es necesario. Configura acciones antes y después. Divide los pasos en pasos de la página de inicio de sesión y pasos de inicio de sesión manual. Ejecuta el conjunto localmente y envía los cambios al canal de integración continua. Utiliza el entorno de nodo como desarrollo y especifica el nombre de usuario y la contraseña. Especifica un archivo JUnit para la salida del informe. Ejecuta Elastic Synthetics en la carpeta de recorridos. Envía el monitor como un monitor de producción. Especifica el entorno de nodo como producción y la clave de API. Utiliza las medidas de seguridad adecuadas. Asegúrate de que los parámetros y las variables de entorno estén configurados correctamente. Utiliza una cuenta de prueba con acciones limitadas. Evita cambios de estado irreversibles.
que nuestras importaciones son diferentes ahora. Así que tenemos un recorrido y una construcción de paso aquí. También verás para el recorrido que en realidad estoy pasando el objeto de página. Este es el objeto de Playwright, y también estoy pasando los parámetros y la configuración. Puedo anular el monitor con la configuración predeterminada, así que si quiero que se ejecute en un horario diferente, con menos frecuencia o más frecuencia, puedo hacerlo. Puedo configurar y desmontar cosas con antes y después, similar a las pruebas unitarias. Y luego tengo dos pasos. Tengo los pasos de la página de inicio de sesión, que son exactamente los mismos que los que cubrimos en el ejemplo de Playwright antes. Y luego también tengo los pasos de inicio de sesión manual, que también se han dividido. Y luego cuando ejecuto esto localmente como desarrollador, todo está en verde. Luego sé que puedo enviar mis cambios. Así que eso significa que cuando se trata del canal de integración continua, hay dos cosas que quiero que haga. Quiero poder ejecutar este conjunto y quiero poder enviar los monitores a producción junto con la implementación. Así que aquí, especificando el entorno de nodo como desarrollo, básicamente para recoger la configuración correcta, y agregando el nombre de usuario y la contraseña para que se recojan esos parámetros, voy a ejecutar el conjunto exactamente de la misma manera que antes con el mismo comando. Así que lo que también haré es especificar un archivo JUnit para la salida del informe, que obviamente no necesité hacer para el desarrollo local. Así que bajando a la línea 18, estoy, ya sabes, ordenando mis instalaciones, estoy iniciando la aplicación en ejecución localmente. Y luego lo que estoy haciendo aquí es ejecutar Elastic Synthetics dentro de la carpeta de recorridos en sí, para que pueda recoger las definiciones, por eso he especificado el directorio de trabajo. Y luego la opción de salida del informe del reportero JUnit significa que mi tarea de publicación de resultados de pruebas unitarias puede recoger esa definición y mostrarme mis resultados de prueba. Pero también necesito enviar el monitor, así que cuando implemento mi aplicación, que ocurre en segundo plano con Netlify cuando este flujo se completa, quiero poder enviar esas definiciones para ejecutarlas como un monitor de producción. Y la forma de hacerlo es especificar el entorno de nodo como producción, especificar la clave de API. Esto debe ser un secreto. No quieres publicar tus claves en tus flujos de trabajo de GitHub visibles públicamente, así que asegúrate de usar un almacén adecuado. Asegurándote de que dependa de las pruebas y no se envíe en caso de que se produzca una ejecución de prueba fallida. Nuevamente, esta vez ejecutando dentro de la carpeta principal de pruebas en lugar de la carpeta de recorridos. Y luego las tareas son que nuevamente ejecutamos las instalaciones y luego ejecutamos el envío, y esto se genera cuando ejecutas el asistente de generación. Y cuando hacemos eso, luego entramos en Elastic. Vemos que tenemos monitores, pero decimos, oh, están fallando. ¿Qué está pasando allí? Necesita poder recoger los parámetros. A menos que los especifiques en la configuración de parámetros globales, no podrá recoger las variables de entorno. Así que debes tener cuidado con eso. También es un buen momento para mencionar que si estás agregando credenciales para estas pruebas, debes asegurarte de que esta sea una cuenta de prueba que se ejecute en producción y esté limitada a realizar acciones específicas. Idealmente,
7. Monitoring, Issue Resolution, and Collaboration
Asegúrese de configurar correctamente los roles para evitar acciones no autorizadas. Monitoree el rendimiento y las fallas. Utilice las mismas definiciones para la comunicación y resolución de problemas. Colabore entre roles y priorice la construcción de aplicaciones amigables para el usuario. Utilice herramientas comunes para flujos de trabajo unificados. No dude en hacer preguntas y acceder a recursos de código. Manténgase conectado a través de varias plataformas.
No queremos que cambie el estado de una manera irreversible. No queremos que pueda hacer cosas como realizar pagos. Por lo tanto, asegúrese de que los roles estén configurados correctamente en su aplicación para asegurarse de que alguien no pueda realizar toneladas de transacciones con una tarjeta legítima en lugar de una tarjeta de prueba o hacer cualquier cosa que no deba hacer. Porque al final del día, si estas credenciales se filtran, debes asumir un escenario catastrófico. También puedes ver cuánto tiempo están tardando, cuántas fallas han tenido en el período de tiempo, y luego podemos comenzar a hacer cosas inteligentes. Podemos ver cuándo falla. Podemos ver en qué paso está fallando. Podemos ver cuál es la traza. Podemos ver cosas como cuánto tiempo tardan los pasos, lo cual es útil para mí porque solía tener una situación en la que mi prueba de intención se volvía cada vez más larga. Entonces, la idea de un monitor es poder ver si está comenzando a ejecutarse un poco más lento y luego puedes averiguar si tal vez están comenzando a degradarse, tal vez haya optimizaciones que puedas hacer para que sea una experiencia más eficiente para el usuario. Eso es todo súper útil. Muchas veces puedes hacer cosas inteligentes como alertas. Ahora, la esperanza es que esto atrape algo antes de que lo haga el usuario, pero eso no siempre va a suceder. A veces, un usuario encontrará un problema y lo que podemos hacer es utilizar estas mismas definiciones como comunicación para lo que está experimentando un usuario. Entonces, si escribimos una especificación o grabamos una especificación, luego podemos usar eso para recrear el problema, trabajar en la solución y luego retroceder desde ese flujo inicial que cubrimos antes. Porque en esta situación particular,
DevOps para mí, dada mi experiencia, dadas los desafíos de los que hablé al principio, se trata de unirnos, asegurarnos de colaborar, independientemente de si somos SRE, ingenieros de
DevOps, desarrolladores, independientemente de los desafíos y las prioridades que tengamos, todos tenemos un objetivo y es asegurarnos básicamente de que estamos construyendo aplicaciones increíbles que los usuarios están felices de usar. Así que es hora de unirnos y si las herramientas comunes pueden ayudarnos a hacer eso, en este caso con las pruebas de extremo a extremo y los monitores sintéticos siendo dos caras de la misma moneda, hagámoslo. Así que la próxima vez que estés revisando tu suite de extremo a extremo o tus monitores scriptados, solo asómate por encima de esa barrera y pregúntate si están escribiendo lo mismo. ¿Los flujos de trabajo están sincronizados? ¿Y realmente hay una forma en la que podamos escribir las mismas definiciones utilizando herramientas comunes? Así que muchas gracias, DevOpsJS, ha sido un placer absoluto. Estaré por aquí, así que no dudes en hacerme cualquier pregunta sobre Playwright, sobre monitoreo sintético, estaré aquí para eso. También puedes sumergirte en el código, que puedes consultar en el código QR que se muestra allí, y también hay una copia de las diapositivas allí. Si no me encuentras por aquí y se te ocurre algo después, estoy en X, estoy en LinkedIn, estoy en Masterdod, solo contáctame y saluda, nos vemos la próxima vez. ¡Adiós!
React Summit 2023
Comments