Monitorización Sintética y Pruebas de Extremo a Extremo - Dos Caras de la Misma Moneda

Hola a todos. Es genial verlos en el React Summit. Mi nombre es Carly Richards, soy una defensora del desarrollo en Elastic. Y quiero hablar sobre el monitoreo sintético y las pruebas de extremo a extremo. Tal vez se pregunten por qué estas cosas pueden parecer construcciones totalmente diferentes. Pero a pesar de la aparición de DevOps y las prácticas de SRE, y de tratar de unir los flujos de trabajo personalizados, descubro que, por diversas razones, todavía estamos utilizando diferentes herramientas para tratar de lograr niveles de automatización bastante similares, aunque en diferentes puntos del ciclo de desarrollo.

Voy a hablar sobre mis propias experiencias y por qué creo que esto sucede. Y luego mostraré cómo podemos unirnos mediante un tooling común utilizando pruebas de extremo a extremo integradas en un tooling de monitoreo sintético, para permitirnos básicamente hacer ambas cosas utilizando los mismos recorridos programados. Así que solía trabajar en un banco antes de unirme a Elastic, y durante la mayor parte de ese tiempo, descubrí que el desarrollo y las operaciones no estaban tan unidos como nos gustaría decir. Básicamente eran facciones en guerra con intereses en competencia, y las mejores prácticas emergentes de SRE y DevOps que surgían en el espacio de la observabilidad a menudo eran adoptadas por la gestión de producción, pero nunca permeaban fácilmente hacia el lado del desarrollo. Y se necesitó mucha persuasión para que eso sucediera. Y honestamente creo que eso se debió a tres razones clave que, lamentablemente, creo que todavía existen en cierta medida hoy en día. La primera es que a menudo tenemos el desarrollo y SRE como departamentos separados o equipos separados, en lugar de ser parte de un equipo multidisciplinario. Y con los departamentos separados y agendas en competencia, la falta de comunicación y empatía tiende a acumularse, lo que puede ser un gran problema porque hace que cada grupo sienta que cuando alguien propone la idea de colaborar juntos, estamos lanzando cosas al otro lado de la cerca para que el otro las recoja y rompa el flujo y básicamente cuestione la dirección en la que sabíamos que debíamos construir como desarrolladores o como SRE. La segunda es que a menudo no hay una priorización común entre estos dos grupos. SRE a menudo puede encontrar defectos menores o tener ideas para la automatización o mejoras en el ecosistema de la aplicación pero con frecuencia se les da una prioridad baja y en su lugar, un propietario del producto presiona por nuevas características para los usuarios que los desarrolladores estarán encantados de construir y nunca abordamos este equilibrio. Y el último desafío que también he visto de primera mano es que a menudo los equipos de desarrollo y producción utilizan diferentes herramientas para lograr objetivos similares. Así que en mi último trabajo en el banco, estábamos utilizando activamente cypress para desarrollar pruebas de extremo a extremo mientras que los colegas de SRE estaban escribiendo automatizaciones similares en Selenium porque se integraba en su plataforma de observabilidad y podían usarlo para monitoreo periódico y verificaciones en la aplicación de producción. Y eso significaba que no podíamos usar realmente las pruebas de extremo a extremo en producción sin que alguno de nosotros cambiara a una nueva tooling. Y la realidad es que las pruebas de extremo a extremo utilizando marcos de automatización para validar el recorrido del usuario a través de pruebas automatizadas y el monitoreo sintético, donde ejecutamos scripts periódicos para verificar la accessibility o los puntos finales o la capacidad de lograr el comportamiento del usuario para asegurarnos de que siga funcionando correctamente, son efectivamente dos caras de la misma moneda. Y si nos unimos mediante un tooling común, podemos utilizar estos mismos scripts no solo como pruebas y herramientas de monitoreo en las mismas suites de aplicaciones en diferentes entornos, sino que también podemos utilizarlos como una forma común de documentar el recorrido del usuario y cómo esperamos que los usuarios utilicen las características de la aplicación. Así que podemos hacer eso utilizando playwright y Elastic Synthetics. La forma en que esto funciona como verán en gris a través de cada uno de los cuadros es que tendremos archivos de recorrido en JavaScript y TypeScript que básicamente utilizarán playwright para automatizar esas interacciones y ejecutarlas localmente como pruebas de extremo a extremo contra una aplicación web que se esté ejecutando localmente. Luego, a través de la revisión de pares, podemos ejecutar los mismos monitores como pruebas de extremo a extremo dentro del pipeline de CI de GitHub o cualquier otro proveedor de CI que estén utilizando. Una vez que llegamos a la etapa de implementación de nuestra aplicación, podemos enviar estos mismos monitores utilizando nuestra propia clave de API al lugar correspondiente, ya sea la ubicación específica de Elastic o nuestra propia ubicación privada en ejecución, para hacer el monitoreo en lugar de la aplicación web de producción, que luego almacenará los resultados dentro de Elasticsearch y pondrá a disposición los paneles en Kibana para que podamos ver qué está sucediendo. Entonces, ¿cómo comenzamos con esto? Bueno, necesitamos crear un proyecto para alojar estos monitores para que puedan mantenerse dentro de el control de origen utilizando ambas partes. La forma más fácil de hacerlo es utilizando el asistente de inicialización después de instalar el envoltorio de Elastic Synthetics Playwright a través de NPM. Le dará una estructura de proyecto de muestra que se verá así, e incluirá configuraciones sintéticas para la configuración específica del proyecto y algunos monitores de ejemplo, incluidos los recorridos en TypeScript que pueden ver allí en la carpeta de recorridos. Luego podemos escribir nuestras propias pruebas de comportamiento basándonos en los ejemplos utilizando Elastic Synthetics. Verán aquí en la parte superior que el objeto de página que es el objeto de página de playwright se expone dentro de nuestro recorrido y también dentro de cada palo.

Y podemos hacer uso de la API de Playwright para realizar acciones como localizar elementos mediante el selector CSS, que puedes ver en la línea 16, utilizando los diversos atributos auxiliares introducidos en las versiones 2017 y posteriores, como obtener por ID de prueba. Podemos realizar clics y acciones que un usuario haría en estos elementos HTML apropiados y luego podemos realizar diversas afirmaciones para ver que el resultado apropiado se muestra allí. Y luego podemos ejecutar estas pruebas localmente y asegurarnos de que todos los cambios asociados con nuestra nueva función se aprueben. Luego podemos ejecutar las mismas pruebas en nuestras tuberías de CI y luego podemos implementar esas mismas definiciones en producción en la ubicación de Elastic Synthetics que le permitirá ejecutar esas mismas pruebas como monitores en su aplicación de producción.

Luego, el equipo de SRE puede monitorear el estado. Pueden ver los pings básicos, pueden ver como se destaca en el fondo de estas tarjetas cuál ha sido la duración a lo largo del tiempo utilizando el gráfico en el fondo. Luego, cuando las cosas salen mal, podemos ver los pasos individuales, podemos ver qué expectativas o errores particulares ocurrieron y luego podemos hacer cosas inteligentes como tener alertas o detecciones de anomalías para intentar detectar si hay una degradación en el rendimiento si estas pruebas particulares están tardando más según nuestras tendencias. Para mí, DevOps siempre ha significado unir a las facciones de desarrollo y SRE. Necesitamos dejar atrás esa carga cultural que ha estado presente durante tanto tiempo y trabajar juntos, y si usamos una herramienta común, hay algunos grandes beneficios en términos de documentar el recorrido del usuario, colaborar juntos, detectar defectos en las pruebas y en producción y, en general, construir mejores aplicaciones para los usuarios. Así que muchas gracias, ha sido genial hablar aquí en React Summit. Espero poder encontrarte en la conferencia y, si no, no dudes en consultar el ejemplo de código en el código QR de la pantalla o también puedes contactarme con cualquier pregunta en currentlyellrichmond. ¡Adiós!