Depuración en vivo de pruebas de extremo a extremo para una aplicación serverless distribuida

Gracias por unirse a nuestro masterclass, espero que le resulte útil. Permítanme presentarme primero. Soy Serkan, CTO de Tandra, cofundador y coautor de Throughout M. Las aplicaciones modernas en la nube, incluidas las aplicaciones de servicio, y las canalizaciones de CI. Y tengo el honor de ser reconocido y nominado como CTO de Servidores de AWS, y también como coorganizador del encuentro Cloud OnService Turkey. Y formé parte del equipo que organizó muchos eventos centrados en AWS, tanto nacionales como internacionales, en Turquía. He estado trabajando e investigando activamente en la era de los servidores durante cinco años. Y les doy nuevamente la bienvenida a todos y le paso el micrófono a Ilker para que se presente.

Gracias Serkan. Soy Ilker. Trabajo como ingeniero de front-end en Tundra desde hace tres años. Sí, Ozan, puedes continuar.

Gracias Ilker. Soy Ozan. Soy el ingeniero de soluciones en Tundra.

De acuerdo, gracias Ozan. De acuerdo, comencemos con la parte aburrida antes de comenzar la parte práctica de nuestro masterclass. Permítanme hablar un poco sobre la agenda de hoy. Hoy, en primer lugar, hablaremos sobre Tundra en general sin tomar demasiado tiempo, por supuesto. Hablaremos sobre qué tipo de producto es Tundra y qué problemas ofrece soluciones. Y luego hablaremos sobre cómo podemos escribir pruebas de extremo a extremo para aplicaciones de servicio y cómo podemos automatizarlo. Luego pasaremos a la parte divertida del masterclass y veremos cómo podemos debug y rastrear las fallas en nuestras pruebas de extremo a extremo utilizando Tundra a través de diferentes ejemplos, fallas de prueba y casos de uso.

En primer lugar, me gustaría presentar brevemente Tundra. Básicamente, Tundra es una solución de rastreo y depuración para aplicaciones, pruebas, canalizaciones de CI y flujos de trabajo. Esto significa que los desarrolladores, probadores e ingenieros de control de calidad pueden utilizar Tundra en muchos entornos diferentes desde el desarrollo hasta la producción, como durante el desarrollo local mediante la integración con su IDE, y CI, CD para las solicitudes de extracción y las canalizaciones de compilación y lanzamiento, y en el entorno de preparación antes de pasar a producción, y luego en producción, por supuesto. Además, Tundra es agnóstico a la plataforma, lo que significa que puede utilizar Tundra tanto en entornos de servicio, como AWS Lambda, como en entornos no relacionados con el servicio, como Docker, Kubernetes y VM, y así sucesivamente, y en muchos entornos de cloud, como AWS, Azure y Google Cloud, y Tundra también está integrado con los proveedores de CI más populares, como GitHub, GitLab, CircleCI y BitBucket, Jenkins, TeamCity y muchos otros están por venir. Y también el otro buen punto, con Tundra, es que aún puede usar Tundra, en su entorno local donde está desarrollando en su IDE. Por lo tanto, no necesita usar Tundra en el entorno remoto. Aún puede usar Tundra con las mismas capacidades en su propio entorno local. Su entorno de desarrollo. Y además de eso, Tundra está integrado con muchos entornos de ejecución populares, incluyendo Java, NodeJS, Python, Go y.NET, y con muchos frameworks web como Express, Quo y Happy para JavaScript y NodeJS, y Spring para Java, y Flask, Tornado, FastAPI para Python, y Asafi.NET para.NET, y así sucesivamente para proporcionar una depuración en profundidad y capacidades de rastreo enriquecidas.

OK, entonces Tandra básicamente tiene tres productos principales integrados entre sí. El primero es Tandra Foresight, que es el producto que vamos a utilizar principalmente hoy en nuestro masterclass, y con Tandra Foresight, puede monitorear sus compilaciones de CI-CD desde un solo lugar. Al encontrar los cuellos de botella en su proceso de CI y optimizar los tiempos de CI, puede reducir el costo de su CI y el tiempo para llegar a producción con confianza. Y además, al monitorear las pruebas y las métricas de ejecución, puede seguir históricamente las fallas y los problemas de rendimiento en sus pruebas. Además, la característica más importante es que puede solucionar problemas fácilmente rastreando y depurando el flujo distribuido entre sus pruebas y las aplicaciones en su prueba de extremo a extremo. E incluso con nuestra función de depuración de viaje en el tiempo, puede grabar la ejecución de su prueba línea por línea y tomar capturas de pantalla durante la ejecución. Con capturas de pantalla, me refiero a que puede tomar capturas de pantalla de las variables locales, argumentos y valores de retorno, y las propiedades de los objetos, y así sucesivamente, y luego puede reproducir la ejecución problemática de la prueba y debug sin tener que reproducir el problema, reproducir el problema de la prueba en su entorno local. A veces no es factible o muy difícil reproducir la misma falla de prueba en local debido a muchas razones como tener el mismo estado, el mismo estado de la base de datos o el mismo estado de la aplicación. Por lo tanto, es muy importante poder debug la falla en el entorno real, en el entorno objetivo. Y Tundra Foresight puede funcionar en integración con muchas herramientas de CI y frameworks de prueba. Actualmente, tenemos integración con GitHub, GitLab, Bitbucket, Travis CI, Circle CI y otras canalizaciones. Jenkins, TeamCity y herramientas de CI, y también estamos expandiendo nuestra integración con el ecosistema de CI de acuerdo con las solicitudes futuras de nuestros clientes y usuarios. Y en este momento, Node.js, JavaScript y los entornos de ejecución de Java son compatibles con las integraciones de JSJ y las unidades celulares. Por otro lado, las integraciones de Cypress y el motor de prueba están en camino para JavaScript y los entornos de ejecución de Java. Y también se planea lanzar el soporte de Python Runtime a través de PyTest a finales de este mes. Esto significa que los usuarios de Python también pueden usar Sundra Foresight y mejorar los procesos de prueba y CI al tener todas las características geniales proporcionadas para otros entornos de ejecución de los que hablaremos hoy. Y luego permítanme comenzar con nuestro segundo producto principal. De acuerdo, entonces el segundo producto principal es Sundra APM, que ayuda a los desarrolladores a rastrear y debug sus microservicios y aplicaciones de servicio que se ejecutan en cualquier plataforma, como Docker, Kubernetes, VM, AWS, Lambda, Fargate, e incluso en local, y así sucesivamente. Y especialmente con el auge de los microservicios, el rastreo distribuido se ha convertido en una parte muy importante del proceso de monitoreo.

Y con Sundra APM, los desarrolladores pueden tener una idea de cómo interactúan sus aplicaciones entre sí, con las bases de datos, servicios en la nube, APIs de terceros, y más. Entonces, cuando hay un problema en el flujo de negocio, los desarrolladores pueden rastrear y depurar toda la transacción de principio a fin para identificar problemas, encontrar el componente problemático o el microservicio problemático. Y, por supuesto, Sundra APM y el sitio Forsythe están profundamente integrados entre sí, por lo que los desarrolladores pueden rastrear todo el flujo en sus pruebas de extremo a extremo fácilmente y pasar a producción con confianza. Y permítanme continuar con nuestro último producto, nuestro tercer producto, Tandra Scikit. Nuestro tercer producto principal es Tandra Scikit, que permite a los desarrolladores depurar sus aplicaciones en el entorno objetivo e incluso en producción, no solo localmente. La motivación es que a veces es difícil reproducir el problema localmente debido a muchas razones. Por lo tanto, creemos que los desarrolladores deberían poder depurar sus aplicaciones en el entorno real, contra servicios y datos reales, no simulados. En este contexto, Tandra Scikit permite a los desarrolladores depurar sus aplicaciones sin detenerse en el punto de interrupción. Por lo tanto, tenemos un nuevo término llamado punto de rastreo, que permite a los desarrolladores depurar sus aplicaciones en el entorno real sin pasar por el punto de interrupción. Y creo que eso es suficiente para la introducción.

Permíteme hablar sobre lo que vamos a hacer hoy, cómo vamos a llevar a cabo el taller. En primer lugar, nos inscribiremos en Tandra, por supuesto, para crear nuestra cuenta y obtener nuestra clave de API que se utilizará en nuestras pruebas y aplicaciones. Luego clonaremos nuestra aplicación de muestra de un blog desde el repositorio de GitHub y la ejecutaremos en Oracle para echarle un vistazo rápido. La aplicación del blog incluye aplicaciones sin servidor implementadas en Node.js para la plataforma AWS Lambda. En Oracle utilizaremos local stack para simular los servicios de AWS y utilizaremos el framework serverless para implementar las aplicaciones en local stack. Básicamente, vamos a ejecutar un entorno de nube de AWS en nuestro entorno local utilizando local stack, sin necesidad de implementar la aplicación en un entorno remoto. Luego iremos a la consola de la API de AdCounter y veremos cómo se comportan las aplicaciones y cómo interactúan entre sí. En este punto, estaremos familiarizados con el producto de la API de Tundra y entenderemos qué hace la API de Tundra. Luego pasaremos a Tundra Foresight. En primer lugar, iremos a la consola de Tundra Foresight para crear nuestro primer proyecto de prueba que utilizaremos en nuestras pruebas de extremo a extremo durante el taller. Luego ejecutaremos nuestras pruebas utilizando los frameworks que ya están disponibles en las diferentes ramas del repositorio de GitHub de nuestra aplicación de muestra. Y, por supuesto, las pruebas fallarán porque hemos inyectado deliberadamente errores en la aplicación para que las pruebas fallen. Utilizaremos Tundra Foresight para rastrear y depurar las pruebas fallidas y solucionar los problemas con la información proporcionada por Tundra Foresight y APM. Y bueno, creo que he completado la parte aburrida y ahora pasemos a la parte divertida del taller. Gracias a todos nuevamente. Detengamos la pantalla compartida. Gracias Serkan, permíteme compartir mi pantalla. Sí. De acuerdo, gracias Serkan por la introducción. Estas son las tecnologías que necesitamos hoy. Primero necesitamos Node.js versión 10 en adelante. Y necesitamos Python 3.6 en adelante. Y necesitamos Docker y AWS CLI. Si ya los tienes instalados en tu máquina, podrás probar estas demos con nosotros hoy. Y por último, necesitas una cuenta de Tundra para monitorear tus pruebas y aplicaciones. Así que vamos a start.tundra.io y creemos nuestras nuevas cuentas. Aquí crearé una nueva cuenta. Lo siento. Sí, sí. Debes ir a este paso de registro para crear una nueva cuenta. Esta es nuestra página de selección de aplicaciones. Estas son las aplicaciones que Serkan mencionó antes, como recordarás, Forsyth, Sidekiq y APM. Hoy vamos a usar principalmente Forsyth para ver cómo van nuestras pruebas. Y usaremos APM para ver qué sucede en el interior de nuestra aplicación. Así que empecemos con Tundra Foresight. Estos son los pasos de incorporación que proporcionamos. Más tarde, puedes dedicar más tiempo a leerlos si quieres. La creación del proyecto es en realidad la parte esencial. Aquí es donde todo comienza, en realidad. También tenemos algunas integraciones preparadas para algunos proyectos de código abierto. Después de mí, Ozan te las mostrará, y eso es todo. Y también, una cosa más, también tengo algunas demos de UI en mi pantalla, así que si quieres echarles un vistazo, pronto aparecerá un enlace. Por favor, presta atención a ellos. Y después de eso, al lado, tengo algunas demos más y algunas pruebas más. Así que vamos. Sí, estamos listos para empezar. Así que creemos un proyecto, integración de IntelliJ Teams-T. Y también tenemos algunas integraciones manuales.

Además de JavaScript, también estamos muy familiarizados con Java. El sitio principal funciona muy bien con Java. Y de hecho, nuestro proyecto está creado. Y si quieres, puedes dedicar más tiempo a leer estas opciones más tarde. Así que, nuestro proyecto está listo. Y vamos a ir a la pestaña de Preferencias. Y aquí está tu clave de API y el ID del proyecto. Así que, necesitaremos estos dos datos más adelante. Por favor, recuerda dónde encontrarlos cuando los necesites. Pero no te preocupes, en realidad te guiaremos en todos estos pasos. Sí.

Ahora mismo, vamos a clonar nuestra aplicación de muestra. Clonar nuestra aplicación de muestra. En realidad, asumo que la mayoría de ustedes ya han creado sus proyectos. Estos proyectos son esenciales en nuestras demos. Por lo tanto, a continuación, primero clonaremos nuestra aplicación de muestra. Así que, continuemos con eso. Y estos son los pasos que tengo aquí, esto explica los pasos, pero también los ejecutaré uno por uno. Así que no te preocupes. Y si necesitas ayuda, nuestro equipo también te ayudará en el canal de Discord o en el chat de Zoom. Así que no te preocupes por eso también. Así que iré a mi IDE y primero... Chrome... Pegar. Sí. Y después de clonar, debes hacer checkout a la rama base. Oops, lo siento. Sí. Y creo que está bien. Sí. Entonces, ábrelo en una nueva, llamémoslo ventana. De acuerdo. Así que esta es nuestra, en realidad, este es el, este es el repositorio de hoy. La parte más importante es colocar la clave de API, la clave de API correcta aquí. Pero sí. Mi terminal también está lista y usaré... Tal vez podamos esperar a que todos obtengan, creen su cuenta de Tundra y obtengan su clave de API. Podemos continuar estudiando la aplicación localmente. Sí, en realidad este es un buen momento para esperar. Sí, gracias. ¿A todos les gustó? Sí, simplemente creemos una cuenta de Tundra y obtengamos tu clave de API como lo hizo Iskair, así que te estamos esperando aquí, y luego después de llegar a este punto y luego podemos continuar iniciando, ejecutando la aplicación localmente para estar sincronizados entre nosotros, y luego sí, estamos esperando en este punto para obtener tu clave de API y colocar la clave de API en tu archivo de Mac. antes de iniciar la aplicación. Así que esperemos un par de minutos, ¿de acuerdo? Sí, por favor y no dudes en hacer cualquier pregunta o cuando necesites ayuda, simplemente avísanos a través del chat de Zoom o el canal de Discord, estamos felices de ayudarte. Así que publiqué el repositorio en el chat de Discord, pero también lo publicaré aquí. Así que si alguien quiere seguir, si carece de acceso a Discord, pueden ir aquí. Veo en nuestro panel que tenemos algunos registros en Kandler, pero no estoy seguro si todos tuvieron la oportunidad de ir y revisar. Sí, por favor avísanos cuando hayas terminado. Y continuemos iniciando la aplicación. En realidad, en este momento no tenemos ninguna ejecución de prueba, pero durante nuestras demos, verás que esta pantalla se llenará con resultados de prueba. De acuerdo.

Creo que hemos esperado suficiente en esta etapa, así que continuaré colocando mi clave de API. Así que vamos a nuestro archivo make. Y luego ejecuto make install primero. Luego ejecuto make start. Verifiquemos. En realidad, no te preocupes por estas pruebas. Nuestro Docker de Vocalstack tarda un poco en iniciarse. Así que estas son pruebas desde el lado de Vocalstack. Tenemos otra cuenta para esto. Este es el proceso de inicio, puede llevar un tiempo.

Mientras estas cosas se están iniciando, en realidad también inicializaré nuestra parte del frontend. Por cierto, cuando ejecutes esto por primera vez, puede llevar algún tiempo obtener las imágenes de Docker requeridas, me refiero a la imagen de local stack Docker para simular el entorno de AWS en tu entorno local. Entonces, sí, descargar la imagen de Docker de local stack puede llevar solo unos minutos para obtener la imagen. Sí, nuestro backend parece estar bien. Por favor, en realidad esta URL del punto final es importante, guárdala en algún lugar o asegúrate de no perder ese punto final, porque lo pondremos en nuestra aplicación frontend.

Estoy inicializando nuestra aplicación React. Sí... Cobró vida...... ves la parte superior...... pondremos nuestro...... URL del punto final aquí, pero debemos mantener esa parte del bloque...... así que ten cuidado con eso.... y configuramos nuestra URL...... sí. Entonces, en realidad esta es nuestra aplicación frontend...... cuando... esto es lo que verás cuando clones el...... repositorio proporcionado. Esta es una aplicación simple. Puedes agregar bloques...... y déjame editar aquí, por ejemplo, título...... monitoreo de texto, y el autor es...... fundador de...... sitio.com. Y el nombre de usuario es Ilker.... y cuando lo envíes...

Actually, I will show you how this application looks in Tandra APM. So let's go to Tandra APM. At this point, it's important to mention that one account is usable for all three products, so you can easily switch from Tundra Foresight to Tandra APM with just a few clicks. Let's go to APM.

When we land on the Thunder APM page, we need to provide our name, company, and position. At this stage, we have just submitted our blog post, which is shown under the 'Submit Blogs' section. Here, we can see the details of what happens behind the scenes. For example, when I click the submit button to add a sample blog, the 'post blog' endpoint is called, and we can see the invocation details. The body of the request contains the data we sent to the 'post blog' Lambda function. We can also see the 'search blogs' Lambda function and its trace. If we open the 'post blog' Lambda function, we can see the full trace and plan.

In Thunder APM, there are three Lambda functions being used. We are utilizing the local stack to deploy and run the applications locally without the need to build and deploy all the packages to the AWS environment and create resources.

Y aquí puedes ver que hay tres funciones Lambda. Básicamente, estamos usando el local stack aquí para implementar y ejecutar las aplicaciones localmente sin necesidad de compilar e implementar todo el paquete en el entorno de AWS y crear los recursos. Así que ese es el beneficio de usar el local stack. Y aquí puedes ver que hay tres funciones Lambda y la primera función Lambda se desencadena desde la puerta de enlace de la API. Y luego, estas funciones Lambda simplemente reciben la solicitud y envían un mensaje a SQS para el procesamiento asíncrono para manejar la solicitud de manera asincrónica y luego simplemente devuelven el código de respuesta aceptado. Y luego otra función Lambda, la función de procesamiento de publicaciones de blog, se desencadena desde la cola SQS y obtiene el mensaje de la cola y procesa el mensaje, y luego envía una notificación al tema de SNS y luego escribe el mensaje, escribe el elemento de publicación de blog en DynamoDB. Y luego también configuramos los flujos de DynamoDB para transmitir los cambios de DynamoDB, me refiero a las actualizaciones y las eliminaciones al flujo, y luego este flujo desencadena la función Lambda, la función de replicación de publicaciones de blog.

Básicamente, estas funciones Lambda simplemente obtienen el contenido de DynamoDB, obtienen las actualizaciones de edición y el elemento eliminado de los flujos de DynamoDB y aplican los cambios a Elasticsearch. Básicamente, estamos utilizando DynamoDB como una tienda de valores clave para acceder a los elementos de publicación de blog. Y también estamos utilizando Elasticsearch para poder buscar a través de los títulos y el contenido de las publicaciones de blog aquí. Y estamos utilizando los flujos de DynamoDB para mantener sincronizados los estados de DynamoDB y Elasticsearch entre sí. Básicamente, cada vez que agregamos, actualizamos o eliminamos un elemento en la tabla de DynamoDB, también aplicamos los cambios reflejados en Elasticsearch. Con Tundra, podemos ver automáticamente todo el flujo de principio a fin. Sin tener este tipo de seguimiento distribuido, es muy difícil encontrar el microservicio problemático o el componente en tu flujo antiguo porque con el auge de los microservicios hay muchas aplicaciones en el flujo de negocio. Entonces, si hay un problema, o el origen del problema puede venir de, puede ser llamado desde un microservicio totalmente diferente. Entonces, en este contexto, tener un seguimiento distribuido adecuado es muy importante para encontrar el origen del problema en tu flujo de negocio. Y creo que este es el momento adecuado para esperar a que todos se pongan al día con nosotros antes de continuar con las pruebas. Sí, en realidad puedo dedicar un poco más de tiempo explicando esta aplicación. Ah, sí. Lo siento, lo siento Stephan. No, no hay problema. Tienes alrededor de cinco minutos para ponerte al día. Entonces, sí, en esta etapa, ya sabes, acabamos de enviar nuestros blogs, y tenemos una configuración así, cuando envías tu blog, otra persona puede revisar tus blogs. Y cuando tus blogs son revisados, verás tus blogs revisados aquí, y si se realiza una revisión, puedes simplemente publicar tus blogs. Y volvamos a nuestra lista de blogs de Summit aquí. Sí, al hacer clic en esto, se abre un modelo, y simplemente edito ese blog, tal vez aquí. Tundra Foresight es una herramienta increíble. Y aceptaré esa publicación. Y después de eso, podemos ver nuestro blog, nuestra publicación se ha realizado en esta parte de Blogs Revisados. Mientras hacemos eso, estamos activando algunas funciones Lambda, y todas estas realmente se pueden ver en la lista de funciones de APM. Como puedes ver, hacemos muchas solicitudes de búsqueda de publicaciones de blog, por lo que está aumentando, está aumentando mucho más rápido. Entonces tenemos el replicador de publicaciones de blog llamado dos veces aquí, y esta publicación de blog revisada es algo nuevo cuando hacemos clic en el botón Aceptar Publicación desde ese modelo, acabamos de invocar esa Lambda en realidad. Así que exploremos más con esta invocación. Y tal vez podamos ver nuestras adiciones aquí. Sí, aquí puedes ver que, esto es lo que ha pasado con nuestra publicación. Como recordarás, agregamos nuestra publicación, captura eso. Y cuando vamos a su traza, todavía está aquí, pero a medida que usamos la aplicación, nuestra topología se vuelve más complicada, pero con APM, puedes observar fácilmente lo que se ha hecho. Y por ejemplo, estos mensajes, puedo mostrártelos. No, este. Por ejemplo, sí, este es mi último intento cuando edité la publicación del blog. Esto proviene de la parte de revisión de publicaciones de blog, pero creo que esto proviene de mi publicación inicial del blog. Sí, como recuerdas, esta es la publicación inicial. Uh, puedes observar qué se ha hecho, uh, con la ayuda de Tandra. Permíteme terminar publicando esa publicación. Sí, haz clic en publicar. Sí, todo está bien. Publiquemos esta publicación. Ahora podemos verla en nuestros blogs publicados. Puede llevar un tiempo. Volvámoslo a ver. Sí. Uh, aquí puedes ver que la publicación está, uh, este es el, este es el estado publicado de esa publicación. Entonces, cuando vamos a, uh, funciones de Tandra, funciones de Tandra APM, uh, la lista ahora acabamos de, sí, esto es lo nuevo, publicar publicación de blog, uh, uh, función, uh, obtener frío. Así que capturamos eso. Y sí, simplemente cambiamos el estado de la publicación a publicado. Y cuando vamos a la traza de esa invocación, uh, sí, al igual que antes, ya sabes, los intentos, uh, el tercero, uh, también se agrega aquí. Esto es, uh, esto, esto, esto proviene de la acción publicada que acabamos de hacer.

Um, sí, en realidad, esta es una revisión rápida de, uh, nuestra, uh, aplicación y el, disculpa por interrumpirte solo para aclarar, así que es posible que hayas notado que hay una, hay una latencia, uh, al buscar la publicación de blog aquí. Entonces, de hecho, uh, el problema no es causado por, uh, por la, por la aplicación en sí o por Tundra en sí. Básicamente, la razón es que, uh, cuando simplemente activamos un punto final, el estado local crea un nuevo contenedor Docker para ejecutar el servicio, um, la ejecución, la aplicación de servicio para ejecutar la función Lambda. Entonces, esa fue la razón por la que vemos algunos retrasos, uh, antes de que pongamos un botón para activar un flujo. Entonces, básicamente, eso es, esa es la razón por la que vemos retrasos en la interfaz de usuario. Así que eso no está relacionado con la lógica de la aplicación en sí ni con el agente de Tundra en sí, está bien. Disculpa, como puedes ver como circunstancia, uh, puedes ver cuántos, uh, cuál es la duración de esa invocación también aquí? Uh, sí. Gracias por la aclaración. Uh, entonces, sí, uh, estas son las, para, como últimas palabras, uh, estas son las funciones lambda. En realidad. Uh, vamos a probar hoy que verás mucho con, con, uh, con estos, uh, trazas. Entonces, en realidad, esto es un, uh, una pequeña, um, cómo puedo decir, uh, introducción, uh, veremos mucho esto hoy en los ejemplos siguientes, especialmente con tareas. Entonces, um, sí, gracias por esa parte. Uh, en realidad, algunas, tal vez puedas continuar con, uh, Tundra Foresight, uh, explicación. Entonces, déjame hablar sobre qué es, uh, qué es Tundra Foresight. Y antes de deep dive en los conceptos que estamos, uh, resolviendo, uh, quiero mostrarte nuestro, uh, entorno de pruebas, que es un foresight que Tundra que está en vivo. Entonces, uh, mis amigos, uh, mis colegas pueden compartir enlaces para ti también. Entonces, en este entorno, uh, básicamente esto es, esto es público para todos, que nosotros, nuestro equipo ha, uh, uh, seleccionado cuidadosamente algunos proyectos de código abierto. Uh, así que aquí está la lista de los pocos proyectos creados, como siete proyectos que integramos con Tundra Foresight. Tundra Foresight con. Y aparte de eso, en la página de inicio, verás que hay muchos más, uh, proyectos de código abierto que intentamos poblar los data en este, en este entorno. Entonces, si podemos, uh, por ejemplo, vamos a usar mucho LocalStack hoy. Entonces, si vamos a la página de prueba de LocalStack, te mostraré un caso de prueba muy simple para, uh, mostrar cómo se ve desde Tundra Foresight y Tundra APM. Entonces, si seleccionamos esto, uh, esto tiene un par de pruebas en él. Y, uh, quiero en esta pantalla, déjame, uh, dar una descripción rápida de lo que está sucediendo aquí. Entonces, uh, aquí está la página de resumen de ejecución de pruebas de tu proyecto, que básicamente si ejecutas tus pruebas en tu entorno local o en tu, en tu entorno de CI, tu flujo de trabajo en su conjunto aparecerá aquí, y verás el tiempo de ejecución, cuántas pruebas pasaron, cuántas fallaron, cuántas se omitieron, etc., y en qué rama, uh, se está ejecutando? Entonces tendrás todos los metadatos para entender qué está sucediendo, así como verás que, uh, déjame, seleccionemos en realidad una prueba compleja para ver, ver, qué están haciendo estos bloques. Entonces, en este caso, en el lado izquierdo, tendrás las suites de pruebas antiguas, uh, separadas entre sí. Y dentro de eso, verás las pruebas específicas y aquí, uh, verás las pruebas más erróneas, las pruebas específicas más lentas. Entonces, este, este tablero de información te dará la capacidad de tomar acción. Entonces, si tu flujo de CI es demasiado lento, si tienes, si tienes una, uh, digamos una prueba defectuosa, uh, lo verás de inmediato. Y, uh, eso es, por ejemplo, haciendo clic en esta, uh, prueba, suite de pruebas. Y, uh, para esta suite de pruebas específica, tendremos toda la información antes o después y, así como el antes y después. Entonces, uh, digamos, digamos que quiero, quiero verificar una de estas pruebas y, uh, en este momento estamos en el deep dive. Entonces, entramos directamente en las pruebas específicas que están fallando, que están provocando una excepción de conexión de redis. Y veremos los registros aquí, que es, uh, que es, uh, capturado por los agentes de Thunder y verás la, uh, esa es una traza de la pila del error. Aquí. Uh, también tenemos un par de pestañas aquí, que es, uh, lo otro importante, uh, tipo es el paso de performance, que muestra un histograma de las últimas, uh, uh, digamos, uh, 10 rondas, 14 ejecuciones dentro de tu retención de data. Verás el, uh, uh, performance de las pruebas específicas, cuánto tiempo llevó. Y si, si falló o pasó en el pasado, en el pasado. Entonces, um, esto es bastante útil para, uh, realmente capturar el efecto de performance de tus cambios. Y aquí están los registros, uh, pestaña de registros, uh, en los registros que si tienes algún registro para eso, uh, específicamente, que en este caso, no tenemos ningún registro. Uh, los verás aquí. Um, y para la segunda toma, uh, tengo una, uh, muy buena demostración. Uh, pronto llegaré a eso más tarde. Uh, pero si tienes una prueba de front-end con, uh, Selenium o browser stack, uh, esas secuencias que grabaste a través de tu prueba aparecerán aquí. Um, entonces veamos, uh, cómo se verá en, uh, Thunder APM. Espero que esta sea una prueba de integración y no una prueba unitaria, en el lado izquierdo, vemos un botón de mapa de trazas, que, uh, como estás usando tu cuenta para los tres productos, puedes hacer clic en este botón e ir directamente a la página de APM para esta, uh, prueba específica, que en este caso, esta es, esta es una prueba y hicimos clic en eso y verás todo el, gráfico de trazas y los spans para esta, para esta prueba y qué está sucediendo con ellos. Entonces, si esta prueba se integra con otros servicios, uh, uh, podrás verlos aquí, uh, lo que te mostraremos en las próximas, uh, demos para, para, para nuestros proyectos de muestra. Pero, um, digamos, digamos, vamos a ir a LocalStack, que sé que hay pruebas muy simples con, uh, con un servicio de rescate adjunto a él. Entonces, esta prueba se ejecutó correctamente en las últimas, uh, en las últimas, uh, no sé cuántas ejecuciones aquí, 10 ejecuciones, supongo. Y si hacemos clic en el botón de trofeo, um, veremos que esta prueba específica se integra, uh, en realidad está hablando con AWS, uh, SQ, SQ.

Y para esta prueba, podrás ver esa interacción aquí. Y si haces clic en eso, verás las etiquetas en los registros que vienen con esto. Así que espero que esto haya aclarado muchas preguntas, pero si tienes más preguntas sobre nuestro entorno en vivo o nuestros productos, no dudes en hacerlas. Y como esto es público, puedes ir y verificar todas las pruebas que están disponibles aquí. Entonces, voy a hablar sobre los conceptos principales ahora que hemos mostrado nuestros productos. Entonces, como Tundra, estamos resolviendo un par de problemas que son difíciles pero no imposibles de resolver. Sabemos que los sistemas distribuidos son difíciles. Es difícil desarrollar, mantener y observar, pero esto es especialmente difícil para los entornos serverless. Nosotros, como Tundra, evolucionamos a partir del mercado de modelado y monitoreo de servicios. Pero ahora estamos sirviendo para tus aplicaciones, tus pruebas, pero este problema de trazado distribuido se originó allí. Actualmente, este trazado distribuido está disponible para todos nuestros entornos de ejecución, pero nuestros principales entornos de ejecución son Java, Python y JavaScript. .NET también está disponible, pero dado que los principales entornos de ejecución que utilizan nuestros usuarios son Java, JavaScript y Python, se nos dirigen desde esos entornos específicos. La mayoría de nuestras características principales están disponibles primero para estos tres. Entonces, hablemos de lo que queremos decir con trazado distribuido. Digamos, por ejemplo, que quieres desarrollar una aplicación que esté integrada con diferentes servicios, lo cual es muy similar a lo que Yilkar mostró antes. Y este es el flujo. No tiene que tener sentido, pero para efectos de presentación, digamos que esto es lo que quieres hacer. Una vez que integres tus lambdas con Tundra, verás un mapa de trazas muy similar, casi idéntico, en el panel de control de Tundra. Entonces, no necesitas integrar DynamoDB xs. Estas no son posibles, pero como Tundra, estamos juntando todas las piezas y completando el rompecabezas por ti. Todo lo que necesitas es integrar tus funciones lambda y nosotros nos encargamos de capturar las solicitudes entrantes y salientes y completar el rompecabezas por ti. Y con este mapa de trazas, también tenemos un gráfico de trazas con todos los spans distribuidos. Todos los spans son visibles aquí. Entonces, este es uno de los conceptos principales que estamos tratando de resolver en Tundra. Espero que hasta ahora no haya preguntas. Continuemos con el segundo concepto, que es bastante emocionante. La ingeniería del caos no es algo que, digamos, no tengas la oportunidad de hacer, o no lo hagas todos los días, pero ahorra mucho dolor cuando se hace correctamente y en el momento adecuado, en el lugar adecuado. Entonces, como práctica, haces un experimento de control en tu sistema distribuido. Simulas el fallo, inyectas latencia, creas una partición de red falsa y ves cómo se comporta toda la arquitectura cuando esto sucede. Cuando haces estos experimentos en un entorno controlado y mientras los observas, es posible que detectes grandes fallos antes de que se implementen en producción. Así que podrás ahorrar mucho dolor a mucha gente. Y para la ingeniería del caos y las pruebas distribuidas, que es algo que hemos mostrado hasta ahora, pero también mostraremos la ingeniería del caos en nuestras próximas demostraciones, nuestra característica diferenciada principal es la depuración de viaje en el tiempo, que tiene dos partes principales. La primera parte es grabar las invocaciones, grabar las solicitudes que llegan a tus servicios. Y la segunda parte es reproducirlas entre tu tiempo de atención. Así que podrás revisar tus invocaciones, tus solicitudes y reproducir toda la instantánea de esa invocación con las variables y los metadatos que están cambiando. Así que podrás ver la depuración en vivo que ya está en el pasado. La razón por la que dedicamos mucho tiempo a la depuración de viaje en el tiempo es que, como mencioné, venimos del mercado de servicios y la depuración de arquitecturas serverless es bastante difícil. Y reproducirlas es casi imposible si tienes un error difícil o algo que sucede fuera de tu vista. Así que cada vez que haya depuración de viaje en el tiempo disponible y habilitada para tus servicios, básicamente, cuando ocurra el error, no necesitarás hacer nada, ya lo habrás capturado y lo verás en Tundra. También mostraremos esta característica para ti. Podrás ver cómo funciona. Muy bien. Hablemos de la característica y lo que viene para Tundra Foresight y Tundra como producto. Entonces, hay dos cosas principales aquí. Una cosa es el Depurador Supremo, que ya te he mostrado la pestaña de captura de pantalla, pero actualmente estamos trabajando en expandir los frameworks que estamos soportando. Por ejemplo, los flicks de navegadores humanos de propiedad propia ya son compatibles, al igual que Java en tiempo real. Pero para los entornos de ejecución de JavaScript y NextJS, estos frameworks y los soportes están en desarrollo.

Así que podrás ver cómo se ve la aplicación para probar el tiempo de ejecución. Aquí puedes ver que hay una solicitud, resaltada en azul, y luego puedes ver que el estado ha pasado al estado de procesamiento, resaltado en verde. No se puede ver el estado de procesamiento. Sí, ha terminado. Sí, sí. Estado finalizado. Y luego simplemente pasamos al estado de procesamiento. Este es un ejemplo de falla en la prueba. Básicamente, puedes ver cómo se ve tu aplicación desde tu perspectiva utilizando la función de depurador de SQL de Tundra. Ok. Lo siento. Lo siento, Ozan, de nuevo. En absoluto. Gracias, Serkan. Así que, en realidad, tengo una demostración diferente, por ejemplo, con BrowserStack. Creo que ahora puedes ver eso. Aquí tienes un ejemplo funcional del depurador de SQL. Hemos utilizado BrowserStack, por ejemplo, que está disponible para el tiempo de ejecución de Java. Y aquí puedes ver una muestra de cómo se realiza una prueba y cómo se ejecuta. Y si haces clic en el lado derecho, hay un enlace de proceso en la pila, que se ha generado a partir de esta ejecución de prueba. Cuando hagas clic en eso, serás redirigido al panel de control de BrowserStack y verás todas las pruebas frontales disponibles y podrás ejecutarlas aquí y tendrás todas las capacidades de este producto, de este marco integrado con Foresight sin problemas. Este es un buen ejemplo de cómo funcionará el depurador de SQL. Espero que aclare muchas cosas. Si tienes alguna pregunta, no dudes en hacerla.

Volviendo a la segunda parte de nuestra función de rendimiento. El Monitoreo de Tuberías de CI es algo en lo que estamos trabajando y estará disponible a finales de noviembre. Actualmente, necesitas integrar tu código y cambiar tu configuración, cambiar mucha configuración y cambiar tu tubería de CI para habilitar Tundra Foresight y ver tus pruebas. Pero actualmente estamos tratando de hacer esto más fácil para nuestros usuarios, para los desarrolladores, por lo que cuando se lance esta función, podrás ver y habilitar Tundra Foresight con unos pocos clics. Instalarás la aplicación de GitHub, darás los permisos y Tundra Foresight se integrará en tus ejecuciones de flujo de trabajo y verás esas diferentes ejecuciones de diferentes repositorios, múltiples fuentes y múltiples proveedores de CI en un panel de control. Desafortunadamente, no tengo ninguna demostración de eso, ya que está en etapa de desarrollo, pero tengo algunas capturas de pantalla de cómo funcionará aproximadamente en el futuro. Aquí tenemos tres repositorios diferentes con información de las últimas cinco ejecuciones de flujo de trabajo disponibles, información sobre la duración promedio de ejecución, la tasa de éxito, etc., así como la información de ejecución de pruebas que se extrae de tu archivo de resultados. Y dentro de estos repositorios también tenemos diferentes gráficos y diferentes... bueno, dentro de la granularidad podrás ver mucha información sobre esta ejecución de flujo de trabajo. Un paso más allá, verás todos estos gráficos de duración y tasa de éxito y todas las ejecuciones anteriores para esta ejecución de flujo de trabajo específica, así como las ejecuciones de pruebas vinculadas a esta. Podrás habilitar Thunder Rapport mediante código con el Monitoreo de Tuberías de CI y todo funcionará perfectamente juntos. Y una vez que avances más, verás los trabajos y los pasos para esta ejecución específica y todos los metadatos disponibles para comprender el origen de esta ejecución, por ejemplo. Estamos muy entusiasmados con esto. Espero que tú también lo pienses. Creo que es mi turno y espero que estos pocos minutos te hayan dado una idea profunda sobre Tundra como producto y su futuro. Creo que ahora puedo pasarle la palabra a Ilker para comenzar la demostración del flujo de trabajo y ejecutar las primeras pruebas para nuestro proyecto. Gracias también. Permíteme compartir mi pantalla. Sí. En realidad, quiero explicar algo más sobre nuestra página de APM. Como puedes ver, acabamos de jugar con esta aplicación de muestra. Y como resultado, tenemos estas invocaciones y estas funciones listadas aquí. Quiero mostrar una página más, que es la página de arquitectura. Este ejemplo tiene en realidad siete lambdas. Y desde esa página de arquitectura, puedes ver cómo interactúan estas cosas entre sí en una vista general. Después de eso, simplemente comenzaré a usar Foresight y mostrarte las pruebas de ejemplo. Antes de eso, solo quería mostrarte que la arquitectura de la aplicación es así.

Y nuestra página de arquitectura realmente ayuda mucho para ver qué hacen estas lambdas o los servicios, etc. Así que tal vez después de la masterclass, mientras juegas con esta aplicación, también puedes visitar esa página de arquitectura.

Desde aquí solo quiero ir a nuestra aplicación Forsythe y cerrar todas estas otras pestañas. Y desde aquí voy a Forsythe. Y desde aquí. Esta aplicación simplemente comenzará a ejecutarse o tal vez la cierro. Y voy, sí, primero, deshago todos mis cambios. Luego, cambio a la rama de prueba uno. Sí, mi rama está lista. Y como puedes ver, ahora tenemos una prueba, que es la prueba de publicación de reseñas. Explicaré los detalles más adelante. Y la parte más importante es colocar la clave de API correcta y los ID de proyecto aquí. También puedes, VB también explicar todos estos detalles en los archivos readme de estas ramas, pero aquí debes estar preparado. Vamos a las preferencias de esta aplicación. Tu clave de API, perdón, tu clave de API está copiada, colócala aquí. Y este es tu ID de proyecto. Colócalo aquí. Sí. Estamos listos. Y ahora, simplemente haré una prueba aquí. Sí, veamos. ¿Qué pasó? ¿Dónde estoy? ¿Debería? Intentemos hacer la instalación primero. Sí, perdón. Sí. Perdón, perdón, perdón. Entonces, en el archivo readme también tenemos una descripción de cómo, o una descripción de cómo configurar este entorno de prueba. Así que puedes ir a tu propio ritmo. Así que eso también está bien. Así que ahora nuestra primera prueba se está ejecutando y cuando hacemos clic en el proyecto, sí, todavía no se captura aquí. O tal vez puedo explicarte qué estamos haciendo con esta prueba. Como dije, esta es una prueba para... Si recuerdas, cuando agregué bloqueadores, su estado es, su primer estado es enviado y aquí probamos que el estado de una publicación de blog cambia de enviado a revisado. Entonces, en esta prueba, primero agregamos una publicación simple, una publicación de blog y luego nos aseguramos de que esté... Nos aseguramos de que se agregue correctamente al buscar los resultados de envío. Sí, objeto aquí. Así que buscamos las publicaciones enviadas aquí y después de eso, simplemente, después de asegurarnos de que nuestra publicación se haya enviado correctamente y esté en estado enviado. intentamos cambiar su estado de enviado a revisado. Y probablemente aquí nos encontraremos con algunos errores y exploraremos juntos qué son estos y cómo solucionarlos. Como puedes ver, ahora mientras nuestra prueba se está ejecutando, puedes ver que ya ha comenzado a aparecer en nuestra página de las últimas ejecuciones de prueba. Y como todavía se está ejecutando en este momento, no puedes hacer mucho. Sí, esto puede llevar un tiempo, hasta dos minutos, para poder entender que la ejecución de prueba ha sido completada. Así que estamos trabajando en ello para minimizar el retraso entre la ejecución de prueba que realmente se ha completado y detectamos que la ejecución de prueba se ha completado. Actualmente, hay algún retraso, hasta dos minutos, antes de marcar la ejecución de prueba como completada en este momento. Por favor, continúa. Sí. De acuerdo. Esta es nuestra primera prueba. Como puedes ver, nuestra prueba ha fallado aquí y muestra un mensaje de error. Y cuando actualizo esa página... Sí, han pasado dos minutos. Se ha actualizado.

Refresco la página y como puedes ver, tenemos una bajo la parte de prueba fallida aquí, pero aún tenemos que esperar un poco más para solucionar algunos problemas en segundo plano. Así que en realidad, en un minuto debería estar listo para hacer clic. Así que exploraremos qué ha fallado. Veamos, refresco la página. Así que si no pudiste seguir el primer paso con nuestro front-end, etc. Después de eso, con estas pruebas de ejemplo, tenemos tres pruebas de ejemplo, esta es la primera. No tenemos ninguna, tal vez no volvamos a nuestra aplicación frontend. Así que todavía tienes tiempo para empezar creando un proyecto y revisando esta rama después de clonar nuestro repositorio. Y sabes lo que tienes que hacer, solo poner estas claves de API e IDs de proyecto en el archivo make y luego ejecutar make install. No cometas el error que cometí yo. Después de eso, cuando ejecutes make tests, aún puedes replicar lo que he estado haciendo ahora mismo. Perdón, refresquémoslo. Ahora nuestra prueba está lista. Vemos que ha fallado, así que profundicemos. Vemos que esta es nuestra página de resumen de ejecución de pruebas. Tenemos una fallida. En realidad, una de nuestras suites de prueba ha fallado. Lo vemos aquí, y vamos más profundo. Sí, esta es nuestra suite de pruebas. Este es un archivo de prueba de bloque de revisión. Y puedes ver que bajo esta suite de pruebas, tenemos una prueba, UpdateBlockStateToReview, que es su nombre, como puedes ver aquí. Vemos que esa prueba ha fallado. Así que nos preguntamos qué le ha pasado a nuestro proyecto y por qué esa prueba ha fallado. Así que vayamos un paso más profundo, y puedes observar más con estas pestañas aquí. Y finalmente, vayamos al TraceMap y veamos cuál es el problema. Como expliqué antes, mientras explicaba las pruebas, consta de tres partes. Primero, publicamos una publicación de blog que fue, vamos a hacer clic y explorar. Ahora mismo no lo recuerdo. Veamos, sí. Como puedes ver, los campos están aquí. Primero, publicamos un blog de ejemplo, y estos son los campos. Y después de eso, buscamos nuestro blog para ver si está disponible en estado enviado, en los blogs enviados. Así que creo que algo salió mal. Así que, sí, está bien. Sí, lo encontré. Ilker, perdón por interrumpir. Vamos a hacer un descanso de cinco minutos después de que termine tu ejemplo. Sí, sí, sí, claro. Creo que tengo como máximo 10 minutos más. Necesito como máximo 10 minutos más. Después de eso, haremos un descanso de cinco minutos. ¿Está bien? Claro, seguro, genial. Terminemos el primer ejemplo y luego hagamos un descanso de cinco minutos, sí. Como puedes ver, buscamos nuestra publicación de blog con estado enviado aquí. Así que no hay problema aquí, pero finalmente, cuando intentamos cambiar el estado de ese blog enviado de enviado a revisado, obtenemos un error y podemos seguir nuestro error desde aquí. Oh sí. Hemos obtenido un error. ¿Qué es? Blah, blah, blah. Así que profundicemos.

Vamos a profundizar. Sí, empecemos con, sí, aquí obtenemos un error. Sí. Cuéntame más. ¿Qué pudo haber salido mal? Dice que para revisar el blog, la publicación del blog debe estar en estado enviado. Así que tal vez tuvimos algunos errores con los estados iniciales de la publicación del blog. Desde aquí podemos ver que busca el estado en DynamoDB con enviado, pero con una sola T. Debería ser una doble T. Entonces tal vez podamos buscar en nuestra página de API para ver eso. ¿Qué pudo haber salido mal? Y aquí lo hemos preparado para ti. Sí, en realidad esto es lo que está mal. Debería estar escrito con dos Ts. Así que sí, encontramos el error. Pero tal vez sin Tundra, habría sido muy, muy difícil para nosotros explorar qué parte está mal. Porque sé que la parte que falla es la parte de revisión de publicaciones de blog. Pero si no pudiera ver esa topología, tal vez podría buscar un replicador o buscar publicaciones de blog, etc. Habría sido muy confuso para mí saber por dónde empezar a buscar. Sí, solucioné el problema aquí y luego volví a ejecutar la prueba. Sí, aún puede llevar unos minutos. Mientras tanto, si tienes algún problema al ejecutar la prueba, siempre puedes pedirnos ayuda y estaremos encantados de ayudarte a que funcione.

De acuerdo. En realidad, ahora tenemos un nuevo sitio en GitHub. Así que vamos a crear un nuevo sitio aquí. Y vamos al sitio web en GitHub. Y si abres ese sitio, puedes ver la versión actual, se ha convertido en NixOS, así que ya estamos implementados en NixOS. Sí, sí, también puedo mostrarlo desde aquí. Sí, tienes razón. Sí, esto es lo siguiente que sigue. Así que, espero. Sí. Tal vez mientras esperamos a que la prueba se complete, puedo hablar sobre la segunda parte de la masterclass. En la segunda parte tenemos otros dos ejemplos, dos ejemplos más de pruebas de extremo a extremo aquí. Y vamos a utilizar las funciones de trazado distribuido, ingeniería de caos y depuración de viaje en el tiempo de Tundra para solucionar los fallos restantes en las pruebas. Por supuesto, la función de depuración de viaje en el tiempo puede ser muy interesante para poder rastrear tu aplicación línea por línea y reproducir el problema más tarde para descartar el fallo en la prueba. Y si necesitas guardar el archivo, puedes usar cualquiera de los dos editores de pantalla de inicio relacionados para descargar o volver a asignar los datos. Así que en realidad nuestro ejemplo es muy sencillo, pero este ejemplo sencillo incluye aún 3, 2, 3, 4, 5 funciones de Lambda que se comunican entre sí y trabajan juntas. Y piensa en un caso más difícil. Por ejemplo, digamos 20 Lambdas. Necesitas probar cómo funcionan juntas estas Lambdas, y en ese caso, sería realmente difícil saber dónde buscar si no tienes una imagen como esta. La parte principal aquí es que esta topología realmente te ayuda a entender dónde buscar. Esa es la clave principal aquí. Sí, digamos que ¿Puedes abrir el mapa de trazado aquí? Digamos que hay un problema con la función BlockPostReaptKeyLambda que no se activa directamente desde la propia prueba. Entonces, en la prueba misma, podremos ver que el ReAView BlockPost o la función postBlockPostLambda se completa correctamente pero hay un problema con la función indirecta de Lambda como BlockPostProcessor o la función BlockPostReaptKeyLambda que impide que el BlockPost se guarde en DynamoDB o Elasticsearch para poder recuperarlo o buscarlo más tarde. Así que en este caso sería difícil encontrar el componente problemático en el flujo sin tener una solución adecuada de trazado distribuido como Tundra. Así que necesitamos un par de segundos más en realidad. ¿Y la prueba todavía se está ejecutando? No, no, la prueba ha tenido éxito, podemos verlo desde aquí También puedo mostrarlo aquí. Pasó, pero necesitamos un par de minutos para resolver los problemas de fondo. Solo un par de segundos tal vez. Esta prueba tomó alrededor de 250 segundos, lo cual puede parecer mucho, pero ya sabes que depende de mi máquina local, host local, etc. Así que, una pila local, lo siento. Sí, se podría haber mejorado. ¿Verdad, Serkan? Sí, la mayor parte del tiempo la ha capturado el proceso de inicio de la pila local. Sí, como puedes ver, estamos bien con nuestra última ejecución de la prueba, no hay errores en este momento. Y cuando haces clic, nuestra ejecución anterior tiene un error y nuestra última ejecución es exitosa. Y cuando hacemos clic en el mapa de trazado, como puedes ver, no hay problemas en este momento. Así que estamos bien con nuestras pruebas, todo es correcto. Digamos, creo que ya lo he comprobado, así que vamos a por ese código. Por cierto, siento interrumpir a Ozan. ¿Alguien tiene algún problema con la prueba 1, el ejemplo anterior, al ejecutar la prueba en sí? ¿Tienes algún problema o necesitas ayuda con el ejemplo anterior? De acuerdo, creo que estamos listos para continuar y si tienes alguna pregunta o necesitas ayuda o tienes algún problema al ejecutar el ejemplo anterior, avísanos. Lo siento, Ozan. De acuerdo, genial. No te preocupes. Así que para la prueba 2 necesitamos revisar la rama Test 2 del TestJS Summit 2021, lo cual ya he hecho. Y he configurado la clave de API y el ID del proyecto según el proyecto de Ilkerz que creó. Así que estamos usando las mismas credenciales aquí. Veamos qué tenemos aquí. Y tenemos una prueba de caos AdBlockhost, que en este escenario, estamos inyectando errores de caos en nuestra arquitectura y ver cómo se comporta cuando ejecutamos la prueba. Así que asegurémonos de que Docker esté en ejecución y como estoy usando AWS CLI 2, tengo que habilitar el entorno virtual de Python, lo cual voy a hacer ahora con los siguientes comandos. Vamos a habilitar el entorno virtual y activarlo y puedo ejecutar el make install. Espero que sea legible con este tamaño de fuente, así que si ejecuto el make install, instalará las dependencias de NPM así como los paquetes de serverless y local stack que necesitamos para esta prueba.

Así que esperemos un par de segundos para asegurarnos de que se hayan instalado correctamente todos los paquetes. De acuerdo, ahora podemos ejecutar 'make tests' para ejecutar nuestras pruebas de caos. Ejecutemos esta prueba y hablemos sobre lo que estamos comprobando aquí, que es casi idéntico a nuestra prueba anterior. Lo único es que no necesitamos hacer la parte de revisión y también estamos inyectando un caos aquí. Mientras esto se está ejecutando, voy a iniciar sesión con la cuenta de Incare en nuestro panel de control de Forsyte. Veamos qué hice mal aquí. Olsan, no Gmail. Debería ser Tandra. Oh, cierto. Lo siento. Lo siento, es un hábito. Sí, vamos con eso. Gracias por señalarlo. Vamos a la aplicación de Forsyte. Y ya vemos que la prueba está aquí. Ya se está procesando. Y tal vez mientras la prueba se está ejecutando, podemos hablar sobre el Motor de Caos. Básicamente, la motivación del Motor de Caos es que queremos simular los posibles fallos que pueden ocurrir en producción, pero queremos probar nuestras aplicaciones contra posibles fallos antes de ir a producción, como los servicios de API de terceros o los fallos de la base de datos o la latencia o los retrasos. Hay dos enfoques para inyectar caos en nuestra arquitectura y el primero es crear caos a través de operaciones de red, simplemente desconectando la conexión de red entre los servicios, entre las aplicaciones, la base de datos, etc., y otro enfoque es inyectar fallos y retrasos en el lado del cliente como hicimos en Tundra. Ya tenemos la capacidad de instrumentar y rastrear las llamadas a las API de terceros y los servicios y bases de datos, también podemos inyectar retrasos y fallos en las comunicaciones con el mundo exterior. Aquí puedes ver que estamos inyectando un error en las operaciones de los servicios de Elasticsearch. Así que tenemos la capacidad de inyectar las llamadas y los fallos y las latencias a nivel de servicio y a nivel de recurso, como un nombre de tabla o un nombre de cola, y también a nivel de tipo de operación. Por ejemplo, podemos decir que solo inyecte latencias en las operaciones de escritura a las tablas de usuarios en DynamoDB y solo operaciones de escritura en la cola de prueba en la cola SQS de AWS, etc. También podemos combinar los diferentes criterios para inyectar la llamada. Aquí estamos utilizando una configuración muy sencilla para inyectar los fallos en todas las operaciones de Elasticsearch. Pero también podemos limitar el alcance solo a índices específicos de Elasticsearch o solo a operaciones específicas de Elasticsearch como lecturas, escrituras o eliminaciones. Hay una variedad de configuraciones disponibles para el soporte de Ingeniería de Caos de Tandra. Gracias Serkan. Aquí estamos inyectando al 100 por ciento. Básicamente, cada vez que ejecutamos la prueba, esta configuración inyectará el fallo en nuestras operaciones. Nuestra prueba ha fallado como esperábamos. Dice que esperaba un blog post y no estoy obteniendo ninguno. Veamos cómo se verá en Tandra. Solo necesitamos esperar un poco para asegurarnos de que esté cerrado. Una buena ventaja del soporte de Ingeniería de Caos de Tandra es que no necesitas cambiar la configuración de nivel de aplicación o de red para inyectar latencias o retrasos. Mediante el uso del agente de Tandra y las configuraciones de forma programática o declarativa a través de variables de entorno, puedes especificar los puntos, los servicios y los recursos y operaciones para inyectar el caos sin realizar cambios en el código a nivel de aplicación. Sin estropear tu propio código solo para inyectar los fallos. Los retrasos. Esta fue otra buena ventaja de usar el soporte de Ingeniería de Caos de Tandra, para simular, imitar el posible caos o los fallos antes de ir a producción. Sí. Verifiquemos de nuevo. Ha fallado. Veamos cómo se verá en APM. Haz clic en el botón de detalle. Vemos el mensaje de error y una vez que hagamos clic en el botón de mapa de prueba, lo siento, me sacó. Lo siento por eso. Veamos. Intentémoslo de nuevo.

Vale. Como puedes ver aquí, se muestra toda nuestra architecture con la prueba. A diferencia de la prueba anterior, no hicimos ninguna revisión, pero publicamos una entrada de blog y esperábamos verla en nuestra instancia de Elasticsearch, y la vemos aquí en este lambda PostReplicator. Si hacemos clic en eso, vemos que en realidad es un error de caos que hemos llamado así, y vemos que hay mensajes aquí y todos los detalles que lo acompañan. Por supuesto, también verás todos los detalles de la solicitud de traza. Esto puede no parecer un error real, pero ese no es el punto. El punto es que, en esta architecture, a veces falla la escritura en la instancia de Elasticsearch, y cómo vamos a abordar esa situación. Esto es para simular ese escenario exacto, un escenario de fallo exacto, y hacerlo en este entorno controlado. Vamos a solucionarlo rápidamente. Dado que no hemos realizado cambios de código y lo hemos declarado a través de nuestra variable de entorno, esta configuración que está fuera de nuestra architecture y se pasa a este lambda, podemos simplemente inyectar el porcentaje y establecerlo en 0, y esto tendrá éxito siempre. También puedes dar condiciones complejas aquí. Así que volvamos a ejecutar la prueba. Esto también llevará un par de minutos. En cuanto al problema de tiempo con las pruebas, como dijo Ilker, depende realmente de los recursos de tus máquinas y, dado que Locust Stack crea todas las instancias de Docker cuando se activa, puede llevar un par de minutos para que se inicien y estén disponibles para nuestras pruebas. Sí, dado que hay muchas funciones de Lambda, es muy recomendable asignar más CPU a Docker para poder ejecutar las aplicaciones y realizar las pruebas correctamente. Por cierto, olvidé mencionar que aquí podemos ver que estamos utilizando la instancia de Elasticsearch, pero no estamos creando la instancia de Elasticsearch solo para la prueba. Hemos creado una instancia pública de Elasticsearch solo para la masterclass. Por lo tanto, puedes utilizar esta instancia de Elasticsearch globalmente, pero cada uno escribe los datos en un índice diferente para Elasticsearch global. Así que no tienes que preocuparte por conflictos de datos con los demás, simplemente utiliza nuestra instancia global de Elasticsearch porque creamos diferentes índices, diferentes instancias de Elasticsearch para cada asistente. Así que ejecuta 'make test' y la aplicación utilizará el índice específico de Elasticsearch para ti. Sí, también puedes probarlo a tu propio ritmo y en tu propio tiempo, y esta masterclass estará disponible para que la veas más tarde. Como puedes ver, nuestra prueba ha pasado y simplemente hemos desactivado la inyección de caos, ese es el punto de esta etapa. Volvamos a nuestro panel de control nuevamente y veamos que está llegando y vemos que hay una prueba exitosa. Una vez que esto termine, veremos este mapa de traza con todas las líneas. Es un poco rápido de ver y se detendrá. Sí, todo está en verde ahora y podemos verlo para asegurarnos en nuestro mapa de prueba, por lo que tenemos la ejecución previa y vamos a nuestro APM y vemos que todo funciona correctamente. Así que espero que este ejemplo te haya dado algunas ideas sobre cómo implementamos la inyección de caos y qué es la ingeniería del caos en general y cómo la vamos a implementar, integrar en nuestras pruebas y en nuestro día a día con nuestras herramientas. Así que ahora puedo pasarle la palabra a Serkan, creo, y dejar de compartir mi pantalla. Gracias Olsan e Ilker por la demostración. ¿Debo esperar unos minutos para que todos puedan probar la prueba uno o la prueba dos antes de continuar con la prueba tres, el fallo tres? Y también, mientras tanto, permíteme compartir mi pantalla. Y esperaré unos minutos aquí antes de continuar con el ejemplo tres. Así que simplemente envíame un mensaje o envíanos un mensaje. Si tienes algún problema al ejecutar la prueba de fallo anterior, prueba uno o prueba dos. De acuerdo, continúo con el último ejemplo aquí. En este ejemplo, vamos a utilizar nuestra famosa función de depuración sin tiempo. Básicamente, aquí vamos a solucionar un fallo intermitente en la prueba. Llamamos fallo intermitente al fallo de la prueba que ocurre solo para algunas entradas y no para todas las entradas. A veces pasa y a veces falla. Debido a ese comportamiento, no es muy fácil hacer que la prueba falle siempre. En este ejemplo, puedes ver que este es el flujo de ejecución exitosa de una prueba. Puedes ver que simplemente activamos los tres puntos finales de la puerta de enlace de la API. Primero enviamos el mensaje de entrada de blog al punto final de la puerta de enlace de la API, y luego se activa la función lambda de publicación de entrada de blog y la cola SQS, y esto activa la función lambda. Y esto escribe la entrada de blog en la tabla de DynamoDB y luego se replica en Elasticsearch para poder buscarla más tarde. Y luego podemos obtener y buscar la entrada de blog más tarde utilizando estos puntos finales de la puerta de enlace de la API. Este es un ejemplo de una ejecución exitosa de la prueba. Por otro lado, también tenemos otra ejecución de prueba fallida. Y en este ejemplo en particular, lo que estamos haciendo es simplemente publicar una entrada de blog en el punto final de la puerta de enlace de la API y luego intentamos obtener y buscar la entrada de blog. Pero desafortunadamente, no podemos buscarla en nuestras pruebas. Por lo tanto, vamos a utilizar Tundra Foresight y APM de manera colaborativa para encontrar el problema exacto, encontrar la razón del problema. Así que volvamos a mi IDE.

Y luego simplemente estoy ejecutando la prueba en sí, pero antes, tal vez debería ejecutar la prueba y luego, mientras la prueba se está ejecutando, debería hablar sobre los detalles de la prueba. Así que primero voy a ejecutar la prueba, pero antes deberías poder ver nuestra rama de prueba tres y déjame compartir el nombre de la rama a través de Slack. Lo siento, a través del canal de Discord.

De acuerdo. Así que... Déjame simplemente iniciar la prueba y luego hablaré sobre la prueba en sí. Entonces, lo que estoy haciendo dentro de la prueba. Y dejemos que la prueba se ejecute. En la prueba en sí, lo que estamos haciendo es lo mismo que en los primeros dos ejemplos. Básicamente, simplemente estamos iniciando el local stack antes de la prueba, y luego simplemente estamos apagando el local stack justo después de la prueba en sí. Entonces, aquí, lo que estamos haciendo dentro de la prueba en sí, es simplemente crear una publicación de blog activando primero el punto final de publicación de blog, y luego en el segundo paso, simplemente verificamos que la publicación de blog se haya guardado en DynamoDB verificando la publicación de blog utilizando su ID. Y luego, cuando el paso dos ha pasado, estamos seguros de que la publicación de blog se ha guardado en DynamoDB y podemos recuperar el elemento de la publicación de blog en sí. Y luego, en el tercer paso, simplemente intentamos buscar el elemento de la publicación de blog llamando al punto final de búsqueda. Entonces, básicamente, este punto final busca la publicación de blog a través de Elasticsearch, y dado que pudimos guardar la publicación de blog con éxito en el segundo paso, y verificamos que la publicación de blog se pudo guardar, porque pudimos obtener el elemento de la publicación de blog por su ID. Por lo tanto, esperamos que esa publicación de blog también pueda buscarse aquí. Y también puedes notar que estamos realizando cambios periódicamente, porque dado que el flujo es asíncrono y basado en eventos, cuando simplemente llamamos al primer punto final y nos devuelve el código de estado aceptado, esto no significa que la publicación de blog se haya procesado y guardado en el almacenamiento. Simplemente indica que la aplicación del sitio del blog recibe la solicitud y la envía a la cola para procesarla más tarde. Por eso estamos verificando periódicamente la verificación para ver si finalmente pasa. Y, en el tercer paso, como dije, esperamos que la publicación de blog pueda buscarse a través del punto final de búsqueda, y luego finalizamos la prueba. Normalmente, los tres pasos deberían pasar, porque simplemente enviamos la publicación de blog primero y luego verificamos si la publicación de blog se puede recuperar, y luego intentamos buscar la publicación de blog para que el usuario final pueda buscarla. Y la prueba aún se está ejecutando, y mientras tanto, permíteme ver qué prueba se está ejecutando. Y la prueba aún se está ejecutando. Y aquí, por supuesto, esperamos que la prueba falle, porque ese es el objetivo de la masterclass. Por lo tanto, estamos haciendo que la prueba falle, y luego utilizando Tundra Foresight y APM para solucionar el fallo de la prueba, y luego corrigiendo la prueba y luego ejecutándola, y luego verificamos la prueba. Verificando que la prueba haya pasado. Y permíteme volver a mi IDE. Aún se está ejecutando la prueba. Y permíteme volver a mi presentación. Como puedes ver, en el escenario de ejecución de prueba fallida, falta una interacción con Elasticsearch en el replicador de publicaciones de blog. Por lo tanto, también vamos a ver este comportamiento en unos minutos, verificando la consola de Tundra Foresight. Pero aquí, es obvio que la razón es que, de alguna manera, la publicación de blog no puede ser indexada en Elasticsearch. Por eso no podemos buscar la publicación de blog a través del punto final de búsqueda. Normalmente, esperamos que, cada vez que escribimos en la tabla de DynamoDB, la publicación de blog también se refleje en la instancia de Elasticsearch para poder buscarla más tarde. Por lo tanto, puedes ver que entre, la única diferencia entre la ejecución exitosa y fallida de la prueba es una interacción faltante con Elasticsearch en el replicador de publicaciones de blog. Solo, lo siento, déjame hacer zoom. Sí, falta una publicación de blog, falta una interacción faltante con Elasticsearch en la función lambda del replicador de publicaciones de blog. De acuerdo, permíteme volver a mi IDE, espero que la prueba haya terminado. Adiós, fallo. Aún se está ejecutando. Y estamos imprimiendo periódicamente, simplemente registrando las respuestas de la API recopiladas aquí. Solo los datos devueltos por la API de código. Solo devolviendo la respuesta del obtener URL de publicación de blog. Y también el punto final de búsqueda. Y luego, cuando obtenemos el resultado de búsqueda, esperamos que haya solo un elemento porque solo enviamos una sola publicación, una sola publicación de blog al punto final de publicación. Y luego verificamos que los atributos, las propiedades de la publicación de blog deben ser las mismas que las propiedades de la publicación de blog que hemos enviado en el primer paso aquí. De acuerdo, la prueba ha fallado. Y dice que esperamos que haya un elemento de publicación de blog en la respuesta, pero de alguna manera no hay un elemento de publicación de blog en la respuesta aquí. Entonces, en realidad esto significa que no podemos buscar la publicación de blog guardada a través del punto final de búsqueda. Pero dado que pasamos el paso dos, esto significa que podemos obtener la publicación de blog por su ID, pero de alguna manera no podemos buscar la publicación de blog a través del punto final de búsqueda.

Entonces debe haber algún problema mientras se sincroniza el contenido de DynamoDB a Elasticsearch para poder realizar mejores búsquedas. Permítanme volver a la Consola de Tundra Foresight. Y dice que la prueba aún se está ejecutando porque lleva un tiempo comprender que la prueba ha finalizado. Bien, la prueba ha finalizado con falla, y como solo tenemos una prueba única, aquí hay una prueba fallida. Y cuando hacemos clic en la prueba en sí, podemos ver el mismo mensaje de falla de prueba, podemos ver los registros impresos durante la ejecución de la prueba aquí. Y cuando hacemos clic en el mapa de trazas aquí, lo siento.

De acuerdo, puedes ver que al principio, simplemente estamos activando el punto final de publicación, y luego esto envía un mensaje al bloque de procesamiento de la cola de publicaciones, y luego esto activa el procesador de publicaciones de bloque, la función lambda, y luego esto activa alguna función, y esto simplemente escribe los datos en la tabla de DynamoDB. Y esto simplemente activa la función lambda, replica la función lambda, pero aquí falta una interacción con Elasticsearch. Normalmente esperamos que la publicación de blog necesite la solicitud de inserción de Elasticsearch. Para comprender el comportamiento de la función lambda en sí, cuando simplemente hacemos clic en la función lambda de replicación de publicaciones de blog, puedes ver que hay un elemento de depuración en este método. Y también cuando haces clic en el método aquí, puedes ver el código real de la función seleccionada. Y luego, utilizando nuestra función de depuración de viaje en el tiempo, puedes avanzar y retroceder a través de la ejecución de la prueba. Y también puedes observar los valores de las variables en el lado derecho. Por ejemplo, al comienzo del método de guardar publicación de blog en el índice, podemos ver el contenido real del elemento de publicación de blog aquí. Y estamos avanzando. Y aquí estamos haciendo una optimización. En lugar de usar un solo índice de Elasticsearch, estamos escribiendo la publicación de blog en diferentes índices. Por lo tanto, estamos generando un código hash a partir del nombre de usuario. Y luego obtenemos el módulo del código hash según el número total de particiones del índice. Y luego simplemente asignamos el contenido de la publicación de blog por su nombre de usuario a un índice específico de Elasticsearch. Por lo tanto, no estamos utilizando un solo índice. Estamos asignando la publicación de blog según sus usuarios a diferentes índices de Elasticsearch para distribuir la carga entre los elementos de la publicación de blog y reducir la sobrecarga del índice en un solo nodo de instancia de Elasticsearch. Entonces, estamos obteniendo el nombre de usuario de la publicación de blog, John Doe, y luego calculamos el código hash y puedes ver que hay un cálculo de código hash aquí. Y luego obtenemos su módulo según la parte del índice del recuento total de particiones del índice. Y luego calculamos que nuestro número de partición es cero. Y luego, cuando avanzamos, podemos ver que simplemente se ramifica a la declaración else aquí porque la razón es que incluso si la partición no es indefinida, si la partición sigue siendo cero, entonces la condición if se evalúa como falsa. Y luego simplemente cambiamos a la declaración else. Normalmente, esta verificación de condición no debería manejarse así. Podemos decir que la partición no es igual a indefinida o algo así. Pero cuando usamos esta declaración, también estamos ignorando y omitiendo el número de partición cero. Por eso fue la razón por la que calculamos la partición como cero. Normalmente, necesitamos escribir en el índice cero de las particiones aquí, ya que esta declaración evalúa la condición como falsa. Simplemente cambiamos a la declaración else. Y aquí estamos omitiendo la ejecución. Estamos omitiendo la escritura en la instancia de Elasticsearch. Por eso es la razón por la que la publicación de blog no puede buscarse a través de Elasticsearch. Esa es la razón por la que la prueba ha fallado. Y también podemos rastrear la prueba en sí línea por línea. Y cuando vamos a la propia prueba de la publicación de blog aquí, puedes ver que hay algunos span con el elemento de depuración aquí. Por ejemplo, cuando hago clic en uno de ellos, puedes ver el código de prueba en sí. Y cuando vamos a la ejecución de la prueba en sí, puedo ver los valores de las variables locales en el lado derecho. Y simplemente estoy creando la URL, y puedes ver la URL de la publicación de blog aquí. Y luego avanzamos, por lo que este es el resultado. Estos son los encabezados. Puedes ver todas las propiedades, puedes observar todas las propiedades de la captura instantánea de las variables durante la ejecución de la prueba en sí. Y luego avanzamos. Sí, simplemente avanzamos de esta manera. Y aquí, simplemente estamos ejecutando. Y estamos ejecutando otra función anónima, y cuando saltamos a la función anónima, podemos ver el plazo real aquí.

Y además, solo podemos ejecutar la tarea real aquí, y cuando saltamos a ella, podemos continuar desde la ejecución de la prueba en el método de prueba, en el método principal de prueba aquí. Entonces, simplemente enviamos una solicitud de búsqueda. Y puedes ver el resultado de la búsqueda aquí. Y puedes ver que no hay data aquí. Y luego simplemente avanzamos y retrocedemos para ver los valores de las variables durante la ejecución de la prueba. Entonces, con el Depurador de viaje en el tiempo de Tanda, puedes rastrear tanto tu prueba en sí como la aplicación en sí, como lo hicimos para la función PostReplicator Lambda, para entender qué está sucediendo en nuestra función Lambda en sí. Y luego, en lugar de intentar replicar el problema en nuestro entorno local, simplemente podemos capturar la ejecución de la prueba problemática y luego reproducir la ejecución problemática de la prueba mejor línea por línea para entender qué está sucediendo internamente. Porque a veces el problema puede estar relacionado con nuestro propio código base, no con el servicio remoto, no con el servicio de terceros. Por eso es la razón por la que este tipo de capacidades de depuración de viaje en el tiempo son muy útiles para identificar problemas.

Y así que permíteme cambiar a mi idea para ver qué hice para tener esa capacidad. Entonces, en la variable de entorno, simplemente indico que dos variables de entorno y un puerto es solo una línea de rastreo, todos los archivos bajo la carpeta de servicio. Y también tengo otra definición de configuración para la prueba en sí. Aquí simplemente le digo a Tandra que rastree línea por línea todos los métodos y los modules bajo la carpeta de pruebas y la carpeta de servicio aquí. Esa es la razón por la que podemos ver los rastreos en la prueba en sí, como los rastreos de depuración de viaje en el tiempo dentro de la prueba en sí y dentro del código del método de servicio de publicación de blog desde el controlador principal aquí. Entonces, sin realizar cambios a nivel de código sin realizar cambios a nivel de código, simplemente puedes especificar la configuración requerida a través de la variable de entorno para tu aplicación, para tu prueba. Y luego Tandra se encargará del resto simplemente para rastrear la ejecución de tu prueba y la aplicación línea por línea y capturando las propiedades de las variables y demás. Y luego podemos entender el problema más tarde.

Por ejemplo, vamos a la función de la propia aplicación y aplicamos la solución aquí. En lugar de simplemente verificar el cero, estamos verificando que la partición no debe ser indefinida. Entonces, si la partición es indefinida, la omitimos. Porque decimos que la partición podría ser indefinida aquí, la razón es que es posible que no podamos calcular el código hash aquí por alguna razón. Esa fue la razón por la que hay una verificación de este tipo aquí, pero la verificación en sí estaba escrita incorrectamente porque no estábamos teniendo en cuenta el valor cero. Y en caso de que el número de partición sea cero, simplemente vamos a la última instrucción aquí. Permíteme guardar la función lambda. Permíteme guardar el código aquí y volver a ejecutar la prueba. Y luego, cuando vuelva a ejecutar la prueba, la prueba debería pasar porque lo hemos corregido. Y luego podremos verificar el comportamiento corregido utilizando la consola de Tundra Foresight.

Ok, dejemos que la prueba se ejecute y volvamos a Tundra Foresight. Aquí en la consola puedes ver que con Tundra Foresight y el ATM. Al principio, puedes ver todo el flujo aquí verificando las interacciones entre las aplicaciones y los servicios aquí. Y también cuando simplemente haces clic. Entonces, cuando haces clic en una de las aplicaciones aquí, puedes reducir el alcance y ver los detalles de la propia aplicación. Por ejemplo, cuando hago clic en la publicación de blog aquí, puedo ver el rastreo línea por línea y el mensaje de la publicación de blog aquí. Esta es la publicación de blog real aquí. Estoy creando los parámetros aquí. Estoy enviando un mensaje a SQS. Y también hay una búsqueda de publicaciones de blog aquí. Y luego simplemente voy aquí. Y solo se especifica el nombre de usuario y el estado para poder buscar el elemento deseado de la publicación de blog aquí. Y estoy creando condiciones aquí. Y simplemente paso por alto la palabra clave porque no la estoy especificando en la prueba. Y he especificado el nombre de usuario aquí. Acabo de crear la condición aquí. Y no hay una marca de tiempo de inicio. Simplemente lo omito, y aquí no hay una marca de tiempo de finalización. Y luego, por supuesto, hay un estado, por lo que esto debería activar otra condición. Y luego simplemente calculo el código hash aquí. Y luego calculo el nombre del índice aquí. Y como la partición es cero, simplemente la omito y busco por el comodín aquí. Ese es el nombre final del índice aquí. Y luego busco la publicación de blog a través de todos los índices de búsqueda elástica comenzando con estos gráficos aquí. Pero como la publicación de blog y las funciones del replicador lambda no pudieron indexar la publicación de blog anterior debido a un error en nuestra propia aplicación. Simplemente omitimos la fase de indexación en Elasticsearch. Y volvamos a mi ID, la prueba aún se está ejecutando. Vuelvo a la consola de Forseyes. La prueba aún se está ejecutando con el código corregido. Espero que la prueba pase. Esperemos. Y mientras tanto, si tienes alguna pregunta o necesitas ayuda con respecto a los ejemplos de prueba justos que hemos demostrado o cualquier pregunta relacionada con los productos de los que hemos hablado. Estamos aquí para ayudarte o responder a tus preguntas. Por cierto, vi una pregunta en el canal de Discord. ah De hecho, el backend está escrito en Node.js, por lo que todas las aplicaciones, las pruebas en sí y la aplicación en sí están escritas en Node.js. Tal vez nos olvidamos de mostrar esa parte. Estas son las carpetas de origen aquí y estas son las funciones lambda y la base de código. Básicamente, todas las funciones están implementadas en el entorno de ejecución de Node.js aquí. Por ejemplo, este es un servidor PL y puedes ver que hay muchas funciones lambda diferentes aquí.

El bloque de búsqueda para la función lambda y el bloque de publicación para la función lambda y los demás. Y por ejemplo, uh, estos, este es la implementación de la API de bloque aquí. Estas son las funciones lambda, uh, las implementaciones de controlador de lambda. Entonces, estas se activan desde el punto final de la puerta de enlace de la API, y luego esto simplemente pasa la lógica de negocio a la capa de servicio, y la capa de servicio simplemente maneja, uh, la lógica. Uh, y luego devuelve la respuesta requerida o los datos a la, a la capa de API a la capa de control. Entonces, de hecho, básicamente estamos, así que solo usamos el lenguaje JavaScript para todas las aplicaciones y las pruebas. Y Mario, ¿esa es la pregunta? ¿Está claro? ¿Es esa la respuesta que estás buscando? Quiero decir, Básicamente estamos apuntando al tiempo de ejecución de JavaScript. De acuerdo. Permítanme volver a la consola aquí. De acuerdo. Estamos esperando a que la prueba sea marcada como completada por Tundra Foresight. Y mientras tanto, permítanme revisar el chat. De acuerdo. Hay alguna pregunta. Hay una pregunta, pero ya fue respondida por el anfitrión. Entonces tal vez los asistentes no puedan ver eso. Entonces, para la pregunta de Mohammed sobre la exportación en PDF, en este momento no tenemos ninguna función de exportación, pero creo que puedes usar una captura de pantalla para generar un informe para tu, pero sí, expandido. Sí. Solo para el mensaje de Mario. Sí. En realidad, no estamos, no estamos usando Python. Entonces, Python se utiliza básicamente por el stack local. Entonces, no dependemos de ninguna biblioteca de Python directamente. Permítanme abrir mi archivo make aquí. Sí, hay un requisito de Python aquí, pero la instalación de Python es necesaria para el stack local y AWS local. Entonces, no estamos utilizando Python directamente desde nuestras aplicaciones. Entonces, simplemente dependemos en gran medida del tiempo de ejecución de NoGS y del tiempo de ejecución de JavaScript. Entonces, básicamente, y de hecho, solo la prueba en sí utiliza el tiempo de ejecución de NoGS desde nuestro local y la función Lambda en sí se ejecuta dentro del contenedor Docker y el tiempo de ejecución de NoGS es gestionado por el stack local. Entonces, básicamente, estas funciones Lambda, por ejemplo, estas, el archivo de servicio GS y estos, uh, los archivos API GS y el código aquí, simplemente se ejecutan dentro del contenedor Docker creado por el stack local. Entonces, simplemente estamos empaquetando todo el código aquí y lo enviamos y desplegamos la aplicación en el stack local y luego el stack local simplemente ejecuta la aplicación dentro del contenedor Docker. Entonces, básicamente todo el código se ejecuta aquí, la prueba en sí y la aplicación en sí misma son solo código JavaScript y base de código. De acuerdo, uh, permítanme ver la consola de Tundra Foresight. De acuerdo. La prueba ha pasado y también cuando voy al mapa de rastreo de la prueba en sí, debería poder hacerlo. Debería observar el comportamiento correcto. Uh, por el repositorio local, la función. De acuerdo. Puedes ver que hay una interacción con Elasticsearch aquí y cuando hago clic en la función replicadora de Lambda, puedo ver que hay una interacción con Elasticsearch aquí y puedo ver el cuerpo del mensaje de Elasticsearch aquí y también cuando hago clic en el elemento de depuración aquí, puedo ver que, uh, hay una cita fija aquí y simplemente calculé la partición, uh, para el nombre de usuario John Doe y el nombre de partición es cero. Y como solo estoy comprobando si es indefinido o no debido a algunos, uh, debido a algunos fallos potenciales al calcular el código hash, pero estoy manejando esta pequeña condición aquí. Simplemente, uh, ramifico dentro de la declaración if aquí, simplemente genero el nombre del índice aquí. Y puedes ver el nombre del índice aquí con la partición cero post seis aquí. Y luego simplemente, uh, busco en Elasticsearch en sí. Cuando salto al, puedo ir al, uh, el objetivo, la operación de Elasticsearch objetivo aquí. Entonces, esta es la URL de Elasticsearch aquí. Y este es el cuerpo de la carga de envío aquí. Y aquí podemos ver cómo podemos usar la función de depuración de viaje en el tiempo para solucionar los fallos en nuestra antigua base de código, porque a veces el rastreo distribuido no es suficiente para, para señalar el problema, el rastreo distribuido te dice el componente problemático. Entonces aquí, con la función de rastreo distribuido, hemos identificado que estas funciones Lambda, el componente problemático, pero sin ninguna, pero sin ninguna función de depuración adecuada, es difícil decir qué está mal con estas funciones Lambda. Entonces esa es la razón por la que hemos utilizado la función de depuración de viaje en el tiempo para comprender qué está sucediendo bajo el capó y con la depuración de viaje en el tiempo sin realizar cambios en nuestra base de código, podemos simplemente rastrear la prueba y la ejecución de la aplicación aquí y comprender simplemente sigue guardando en la instancia de Elasticsearch debido a un error en nuestra propia base de código, y luego simplemente aplicamos la corrección y ejecutamos la prueba y pasamos la ejecución de prueba fallida anteriormente. Entonces, con la ayuda de la función de depuración de viaje en el tiempo, podemos fácilmente identificar los problemas relacionados con errores en nuestra propia base de código para nuestras pruebas de extremo a extremo. Por lo tanto, tener las dos partes del rastreo, quiero decir, el rastreo distribuido y la función de depuración de viaje en el tiempo es muy crucial para tus aplicaciones distribuidas. Entonces, incluso en tu entorno local o incluso en tu entorno de CI antes de la producción o incluso en la producción, es muy importante tener ambas partes. Quiero decir, la parte de rastreo y la parte de depuración es muy importante para encontrar problemas porque con el rastreo distribuido, solo encuentras el componente problemático. A veces, el componente problemático puede no ser el servicio de terceros y el problema podría estar relacionado con tu propia base de código y con la función de depuración de viaje en el tiempo, puedes comprender el problema en tu propia base de código sin tener que reproducir el problema en tu entorno local.