1. Introducción a la Charla
Hola a todos. El título de la charla es aumentar la confianza de tu aplicación, utilizando CICD e infraestructura como código. Voy a hablar sobre cómo puedes aprovechar la integración continua, la implementación continua, junto con CICD, junto con infraestructura como código para implementar pruebas que puedan determinar si tus implementaciones están rotas después de ser desplegadas en los entornos objetivo. Discutiré cómo puedes aumentar la confianza de tu aplicación dentro de tus lanzamientos utilizando CICD e infraestructura como código. Mi nombre es Angel Rivera. Soy un defensor del desarrollo en CircleCI. Me involucro con la comunidad a nivel de base, discutiendo tecnología y aprendiendo de las experiencias de los desarrolladores. Puedes conectarte conmigo en Twitter en punk data.
Hola a todos. Quiero agradecerles a todos por asistir a mi charla hoy. El título de la charla es aumentar la confianza de tu aplicación, utilizando CICD e infraestructura como código. En esta charla, voy a hablar sobre cómo puedes aprovechar la integración continua, la implementación continua, junto con CICD, junto con infraestructura como código para básicamente implementar pruebas que puedan determinar si tus implementaciones están rotas después de ser desplegadas en los entornos objetivo. Aquí hay una agenda que he preparado para esta charla. Una introducción muy rápida sobre mí mismo y lo que hago en CircleCI. Luego voy a entrar en una breve discusión sobre testing. Y luego vamos a hablar sobre implementaciones rotas, ¿verdad? Y finalmente, voy a discutir cómo puedes aumentar la confianza de tu aplicación dentro de tus lanzamientos utilizando CICD e infraestructura como código. Y luego quiero terminar con una demo que mostrará todos estos conceptos en acción.
Entonces, mi nombre es Angel Rivera. Soy un defensor del desarrollo en CircleCI. Y básicamente lo que hago como defensor del desarrollo es involucrarme con la comunidad a nivel de base. Cuando estoy involucrado con la comunidad, estoy discutiendo todo lo relacionado con la tecnología, ¿verdad? No importa si está relacionado con CICD o DevOps. Me interesa aprender cómo las personas, especialmente los desarrolladores están utilizando la tecnología y algunos de los problemas que tienen con la tecnología también, ¿verdad? He estado en la industria durante buena parte de 27 años ahora. Así que tengo bastante experiencia y me gusta compartir parte de mi experiencia y conocimiento con la comunidad, ¿verdad? Especialmente cuando están luchando con cosas. Y por cierto, también estoy aprendiendo de todos, ¿verdad? Así que no es una calle de un solo sentido donde solo estoy como, ya sabes, volcando data o mi experiencia en la gente. También estoy aprendiendo de la experiencia de otras personas. Y con esos aprendizajes, los traigo de vuelta a CircleCI para que podamos aprovechar esa información en la determinación de las próximas características que vamos a construir para que podamos agregar valor en lugar de simplemente, ya sabes, construir características solo para construirlas. De todos modos. Entonces, si alguien está interesado en tener conversaciones conmigo después de esta charla, pueden contactarme en Twitter, mi nombre de usuario de Twitter es punk data. Generalmente, es la forma más fácil de comunicarse conmigo en estos días. Así que, por favor siéntanse libres de contactarme y discutir lo que quieran discutir. Estoy abierto a
2. Understanding Different Types of Testing
Las pruebas son cruciales para comprender y comparar los resultados esperados de nuestras aplicaciones. Hay diferentes tipos de pruebas, como pruebas unitarias y pruebas de humo, que se centran en funcionalidades específicas y están diseñadas para ser rápidas. Por otro lado, las pruebas de integración funcional y las pruebas de regresión son más completas y lentas, pero aseguran resultados esperados. Las pruebas de humo, como las que utiliza un fontanero para verificar fugas en las tuberías, tienen un alcance limitado y proporcionan una forma rápida de identificar problemas.
todo tipo de conversaciones. Muy bien. Lo primero de lo que quiero hablar es sobre las pruebas, ¿verdad? Porque aprovechamos las pruebas para comprender cómo se comportan nuestras aplicaciones. Y también para entender si se comportan como esperamos, ¿verdad? Entonces, tenemos que implementar pruebas para comprender y comparar los resultados que esperamos, ¿verdad, de nuestras aplicaciones? Y, por supuesto, tenemos que crear casos de prueba. Y cuando estamos comparando esos resultados, queremos asegurarnos de que, nuevamente, estamos obteniendo los resultados que esperamos según los requisitos del sistema o los requisitos comerciales, ¿verdad, que estamos automatizando en nuestros programas? Sin embargo, hay varios tipos de pruebas, ¿verdad? No todas las pruebas son iguales, por así decirlo. Y aquí hay una lista de algunos de los tipos de pruebas más comunes que ejecutamos o desarrollamos como desarrolladores. La primera de la que quiero hablar es la prueba unitaria y la prueba de humo, que son básicamente pruebas diseñadas para tener un alcance limitado, ¿verdad? Se centran en funcionalidades específicas. Y lo que hacemos allí es tratar de detectar cualquier tipo de errores comunes o errores que sean un patrón común o errores de práctica común, ¿verdad? Cosas como, ya sabes, ¿el tipo de datos de una variable o los valores que tiene el tipo de datos o la variable, son enteros, cadena, ¿verdad, flujo, son compatibles dentro del marco? Esas son las cosas que estamos probando. También podemos estar probando si obtenemos respuestas 200 correctas del servidor. Cosas así. Tienen un alcance muy limitado, se centran en funcionalidades específicas y casos de uso específicos. Además, están diseñadas para ser muy rápidas, ¿verdad? No queremos probar cosas a un nivel exhaustivo, ¿verdad? Entonces, nuevamente, estas pruebas unitarias y pruebas de humo están diseñadas para ser rápidas para que, nuevamente, obtengamos una buena sensación sobre el código que estamos construyendo. Y la mayoría de las veces, estas pruebas son excelentes para identificar rápidamente y mitigar cualquier cambio que pueda romper algo. Después de hablar sobre esas pruebas rápidas, de alcance limitado, quería hablar sobre las pruebas de integración funcional y las pruebas de regresión. Nuevamente, estas pruebas tienen un alcance más amplio, lo que significa que son más completas, tocan mucho más código para asegurarse de obtener los resultados esperados. Por lo general, estos tipos de pruebas son más lentos, ¿verdad? Porque son más completas, ¿verdad? Porque hacen muchas más cosas. Pueden estar conectándose a otros servicios que utiliza tu aplicación. Uno de los otros valores, o en realidad, la falta de uno de los otros factores es que son muy costosas. Y con eso me refiero a que pueden ser costosas financieramente. También pueden ser costosas en términos de mano de obra, como el tiempo de los desarrolladores o del equipo de operaciones, ¿verdad? Por ejemplo, si estas pruebas se están ejecutando, tal vez alguien las esté supervisando debido a, ya sabes, mientras se están ejecutando debido a algunas de las complejidades de estas pruebas. Y nuevamente, tienden a ser pruebas más lentas y más completas. Y eso está bien, ¿verdad? Son cosas que se ejecutan, diría yo, más como una experiencia de extremo a extremo, ¿verdad? Para que abarques completamente todas las funcionalidades dentro de la aplicación. Ahora, la razón por la que menciono esto es porque quiero comenzar a hablar sobre las pruebas de humo, que son básicamente pruebas que, nuevamente, son super rápidas y de alcance limitado. Y antes de comenzar, te contaré una pequeña historia. Cuando era adolescente, trabajaba en una empresa de construcción durante los veranos, ¿verdad? Trabajaba con personas en la construcción. En realidad, me emparejaron con un fontanero y el fontanero estaba allí, básicamente instalando nuevas tuberías en esta nueva instalación en la que estábamos trabajando. Pero cuando terminó de soldar todas las tuberías de cobre y asegurarse de que las tuberías de agua estuvieran completas, terminó conectando este aparato de humo, ¿verdad, como una máquina de humo? Y yo estaba curioso acerca de por qué lo estaba haciendo. Así que le pregunté y básicamente me dijo que, bueno, si llenara estas tuberías con agua para probar mis conexiones y asegurarme de que estuvieran selladas correctamente, podría ser un gran desastre porque si tuviera una fuga en algunas de las uniones o si no estuvieran soldadas correctamente, podría haber agua salpicando por todas partes. Entonces, en esencia, lo que estaba haciendo era esta prueba de humo, ¿verdad? Estaba conectando el aparato de humo, bombeando humo a través de él, y era una forma limpia y fácil,
3. Smoke Tests and Continuous Deployment
Las pruebas de humo ayudan a revelar fallas inesperadas rápidamente, eliminando la necesidad de pruebas exhaustivas costosas. La integración continua permite la colaboración y comentarios rápidos sobre los cambios de código. La implementación continua automatiza el despliegue de nuevo software en entornos objetivo. Las implementaciones pueden fallar inesperadamente, afectando el acceso de los usuarios a nuevas funcionalidades.
una forma rápida para que él descubriera si había alguna fuga en sus conexiones. Y la forma en que podía saberlo era obviamente, si el humo se filtraba por alguna de sus conexiones, entonces él sabía exactamente dónde ir, ¿verdad, para solucionar el problema? Y eso es lo que, solo quería compartir eso contigo porque cada vez que veo la palabra prueba de humo, me recuerda un poco a esa experiencia cuando era adolescente. Y más adelante en mi carrera, hice esa conexión, ¿verdad, lo cual es bastante gracioso en mi caso. Entonces, nuevamente, las pruebas de humo te ayudan con tu prueba preliminar, te ayudan a revelar cualquier tipo de fallas, ¿verdad, que no se esperan? Nuevamente, súper rápidas y muy enfocadas. Ahora nuevamente, es esencial porque, ¿verdad, te brinda la oportunidad de, ya sabes, nuevamente verificar que tu código esté funcionando según lo planeado o como se espera. Y también te ayuda a eliminar esas pruebas exhaustivas más costosas y de larga duración, ¿verdad? Puedes ejecutarlas en una etapa posterior de tu ciclo de desarrollo de software.
Ahora que hemos cubierto pruebas, especialmente las pruebas de humo, ¿verdad, que son rápidas, rápidas y enfocadas, quería hablar sobre implementaciones fallidas. Ahora, con implementaciones fallidas, ¿verdad, deberíamos poder aprovechar la entrega continua, que es la práctica de construir, probar y entregar cambios de código utilizando herramientas automatizadas. Dentro de la entrega continua, tenemos este concepto de integración continua e implementación continua, ¿verdad, CICD, nada nuevo ahí, creo que mucha gente entiende qué es eso. Pero con la práctica de la integración continua, lo único que haces es básicamente colaborar en torno a código con los equipos de tu organización o tus compañeros de trabajo, ¿verdad, o los miembros de tu equipo? Y básicamente lo que estás haciendo es fusionar todas las copias de trabajo o cambios de los desarrolladores en un repositorio de código compartido, para que puedas colaborar en ese código como equipo, y también el desarrollador individual puede obtener comentarios rápidos sobre los cambios que hicieron, ¿verdad? Entonces, cuando subes código y se ejecuta a través de tu canalización de CICD, puedes hacer todo tipo de pruebas, todo tipo de verificaciones, todo tipo de compilaciones, cualquier acción que necesites automatizar. Y luego puedes obtener esa retroalimentación súper rápida. Para que, ya sabes, puedas solucionar los problemas que se identifican dentro de la canalización. Y luego, ya sabes, volver a trabajar en el código en el que se supone que debes estar trabajando, en cosas nuevas, ¿verdad? Entonces, con la implementación continua, es solo una especie de seguimiento de tu CICI con procesos de integración continua. Y básicamente, lo que eso significa es la práctica de implementar automáticamente este nuevo software en los entornos que estás apuntando, ¿verdad? En este caso, esta imagen muestra que estamos construyendo un artefacto de imagen de Docker, y luego lo vamos a implementar en un clúster de Kubernetes, que luego estará disponible para tus usuarios activos. Ahora, generalmente trabajamos con implementaciones de camino feliz, ¿verdad? Y básicamente, esto es donde todos los trabajos se completan con éxito, ¿verdad? Tienes todo, desde, ya sabes, escribir el código, subirlo a tu repositorio de código, y luego la canalización de CICD, ya sabes, iniciando y haciendo todas las cosas que has definido en tu archivo de configuración de canalización de CICD. Y luego al final del día, simplemente exponiendo tu código o implementando tu código en Kubernetes, y luego exponiendo ese código a tus usuarios para que lo puedan usar en tus servicios. Ahora, puedo decirte que, ya sabes, cuando tienes estas implementaciones, algunos de los resultados previos a la implementación, especialmente dentro de las canalizaciones de CICD, pueden ser engañosos. Obviamente, ¿verdad, las implementaciones siempre fallan inesperadamente? No diría siempre, pero predominantemente fallan inesperadamente. Y está bien, ¿verdad? Es una práctica común. Y en este diagrama aquí, ¿verdad, te muestro que, ya sabes, mi canalización pasó por todas las etapas. Implementó mi imagen de Docker en Kubernetes, pero una vez que se implementó, no hubo problema con la implementación. La aplicación tal vez no se inició correctamente, o simplemente no funciona como se diseñó, lo que luego afecta, ¿verdad, la capacidad de los usuarios de acceder
4. Common Deployment Failure Reasons
Las configuraciones defectuosas, los fallos de integración y las credenciales inválidas son razones comunes de fallos posteriores a la implementación. Aprovechar CICD y la infraestructura como código puede ayudar a reducir la cantidad de implementaciones fallidas.
para acceder a esta nueva funcionalidad en nuestra implementación. Entonces, aquí están algunas de las razones comunes de fallos posteriores a la implementación, ¿verdad? Este es uno importante, las configuraciones defectuosas, ¿verdad? Cuántas veces, quiero decir, estoy seguro de que como desarrolladores, todos hemos enfrentado esto, ¿verdad, donde, ya sabes, algo ha cambiado en el entorno objetivo, ¿verdad, pero nosotros como desarrolladores no entendemos qué fue eso, o simplemente no estamos al tanto de ello. Y tenemos que volver atrás, ¿verdad, y reconfigurar las configuraciones para nuestra aplicación. Así que eso es uno importante. El siguiente es un fallo de integración, que considero un fallo de integración como una situación en la que, tal vez te estás conectando a una API de terceros, o una base de datos de terceros, y tal vez ese servicio al que te estás conectando está caído, ¿verdad, tal vez tuvo un problema ese día, o hay algo sucediendo con el servicio que está básicamente fuera de tu control, ¿verdad, y es el servicio con el que estás integrando que no controlas y no puedes solucionar. Otra razón de fallo en la implementación podría ser credenciales inválidas, autenticación, este es en realidad uno de los más comunes, ¿verdad, así que tal vez un token de API ha expirado o ha sido revocado, o tal vez simplemente tienes una contraseña o nombre de usuario incorrectos, sea cual sea el caso, estas son las tres razones más comunes de fallos en la implementación. Ahora que he descrito los fallos en las implementaciones y especialmente dentro de una canalización de CICD y las diferentes razones por las que las cosas están fallando, veamos, ya sabes, cómo podemos aprovechar CICD y la infraestructura como código para ayudar a reducir la cantidad de implementaciones fallidas.
5. Expectations and Failed Deployments
En la actualidad, se espera que los desarrolladores y los ingenieros de DevOps avancen rápido, con confianza y de manera confiable. Esto significa escribir y desplegar código a un ritmo rápido. Sin embargo, es crucial lanzar código confiable sin errores. Por ejemplo, una implementación de producción fallida puede ocurrir cuando la aplicación no funciona como se espera después de ser desplegada en Kubernetes.
Entonces, ya sabes, en la actualidad se espera que los desarrolladores y los ingenieros de DevOps, o ya sabes, cualquier persona prácticamente en el campo de la tecnología en lo que respecta al código, avancemos rápido, con confianza y de manera confiable. Eso significa que, ya sabes, estamos escribiendo código a un ritmo récord y luego también estamos desplegando ese código casi al mismo tiempo, ¿verdad? Así que cuando avanzamos rápido, con confianza y de manera confiable, queremos poder hacer eso, ya sabes, mantener nuestros ciclos de lanzamiento a una velocidad muy buena, pero también queremos lanzar código confiable o código de calidad y sin errores. Así que aquí tienes otro ejemplo, ¿verdad? Vimos anteriormente la implementación de producción fallida. Mientras, ya sabes, estamos ejecutando una canalización de CICD hasta el punto en el que estamos construyendo nuestra imagen para nuestra implementación de producción en Kubernetes. Y nuevamente, ¿verdad? La aplicación se despliega en este diagrama y una vez desplegada, la aplicación no
6. Deploying and Testing with Infrastructure as Code
En este diagrama, aprovechamos la infraestructura como código para crear un entorno objetivo de Kubernetes, implementar el cambio de la aplicación en un contenedor, realizar pruebas de humo de las implementaciones y luego destruir el entorno. Esto asegura que la aplicación se implemente, pruebe y los administradores de lanzamiento puedan tener confianza en la implementación. El diagrama muestra una ejecución paralela, con dependencias al implementar en Kubernetes. Ejecutar pruebas de humo y destruir la infraestructura creada verifica el artefacto en la canalización.
funcionando como se espera. Entonces, lo que estoy proponiendo aquí es, en este diagrama, ya sabes, todo está hasta el mismo punto, ya sabes, digamos que es una canalización en la que, ya sabes, los desarrolladores envían algún código, se construye la imagen y en este caso, vamos a aprovechar la infraestructura como código para crear un entorno objetivo de
Kubernetes. Luego vamos a implementar ese cambio de aplicación en forma de un contenedor. Y luego vamos a realizar pruebas de humo de esas implementaciones, ¿verdad? Y una vez que todo eso ha pasado mi prueba, vamos a destruir todo, ¿verdad? El clúster de
Kubernetes, vamos a destruir los servicios de contenedor, todas las cosas que se crearon en ese entorno objetivo de creación. Entonces, lo que eso te brinda básicamente es la capacidad de saber que tu aplicación se ha implementado en el entorno objetivo y luego, ya sabes, se ha probado con pruebas de humo. Y luego, ¿verdad?, puedes destruir todo ese entorno porque no lo necesitas, ¿verdad? Y nuevamente, esto ayuda con la gestión de lanzamientos de ese producto. Entonces, tus administradores de lanzamiento saben que, hey, este cambio, estos cambios de código, se empaquetaron, se implementaron en un clúster de
Kubernetes, se probaron, funcionan y podemos, ya sabes, básicamente tener una mayor confianza en esa implementación. Entonces, este es un diagrama del panel de control de CircleCI, que muestra una forma rápida, ¿verdad?, y esto también está en mi demostración. Pero básicamente, lo que estoy mostrándote aquí es que puedes ejecutar cosas en paralelo. Todas están conectadas, ¿verdad?, hasta un punto en el que tienes dependencias, especialmente cuando estás implementando en
Kubernetes, tienes que crear un clúster para hacerlo. Y finalmente, vamos a ejecutar algunas pruebas de humo y luego destruir todo lo que hemos creado. Así que, ya sabes, no necesitamos esa infraestructura y luego tu artefacto en tu canalización está verificado y el equipo de gestión de lanzamiento de tu aplicación simplemente tiene ese factor adicional o una buena sensación al saber
7. Implementing and Leveraging Infrastructure as Code
Al implementar estas cosas, implementa la aplicación y realiza pruebas de humo en el entorno objetivo para asegurar resultados esperados. Esto ayuda a desarrollar canalizaciones rápidas y aprovechar la infraestructura como código para crear y destruir entornos objetivo fácilmente. Se recomienda investigar la infraestructura como código y adquirir competencia en ella para comprender cómo implementar cambios de código en infraestructura real. La infraestructura como código no solo permite realizar pruebas en entornos reales, sino que también permite gestionar y controlar los cambios dentro de los entornos objetivo.
que esto se ha ejecutado en un clúster de
Kubernetes. Entonces, nuevamente, cuando estamos implementando estas cosas, vamos a implementar la aplicación, realizar pruebas de humo para probar la aplicación dentro de su entorno objetivo. Así entendemos y sabemos que estamos viendo los resultados que esperamos. También ayuda a desarrollar canalizaciones rápidas, para que puedas realizar pruebas de humo nuevamente en todas tus implementaciones, y puedes aprovechar la infraestructura como código para crear y destruir estos entornos objetivo muy fácilmente. Recomiendo encarecidamente que, si aún no lo estás haciendo, investigues sobre la infraestructura como código, hay muchas herramientas disponibles para ayudarte a comenzar. Pero definitivamente es algo que creo que todos los desarrolladores necesitarán en el futuro cierta competencia, para comprender cómo llevar sus cambios de código desde, ya sabes, básicamente su computadora portátil o repositorios de código a la mundo real y a alguna infraestructura real. Con la infraestructura como código, también, ¿verdad?, no solo obtienes esa capacidad de probar tu código en entornos reales, sino que también puedes gestionar y controlar los cambios dentro de tus entornos objetivo utilizando la infraestructura como
8. Benefits of Smoke Testing and Demo
Las pruebas de humo proporcionan información valiosa sobre las implementaciones y lanzamientos de aplicaciones. Ayudan a detectar errores faltantes y verificar el comportamiento de la aplicación en los entornos objetivo. Las versiones de software fallidas deben ser rechazadas. La demostración mostrará los conceptos en acción, comenzando con la activación de la canalización, la prueba de la aplicación y su implementación en un clúster de Kubernetes utilizando infraestructura como código.
La infraestructura como código. Entonces, nuevamente, ¿verdad?, este es un concepto que no va a desaparecer. De hecho, probablemente se fortalezca aún más con el tiempo en la industria. Así que solo quería compartir los beneficios de las pruebas de humo antes de pasar a la demostración. Nuevamente, ¿verdad?, obtendrás información valiosa sobre tus implementaciones y lanzamientos de aplicaciones. Es una forma sencilla de detectar cualquier tipo de errores faltantes, ¿verdad? Entonces, si solo estás implementando cosas o escribiendo código y no realizas pruebas, probablemente no estés detectando ningún error. Así que intenta utilizar al menos algunas pruebas unitarias o de humo para acostumbrarte a detectar estos errores antes de lanzarlos al mundo. Y también estás verificando el comportamiento de tu aplicación, ¿verdad?, dentro de esos entornos objetivo donde se van a implementar. Y finalmente, rechaza todas las versiones de software fallidas, ¿verdad? Es bueno saber que hubo problemas, pero obviamente no quieres empaquetar esas versiones fallidas en un artefacto y luego implementarlas en
Kubernetes.
Entonces, ahora pasemos a la demostración y te mostraré cómo todos estos conceptos se unen. Así que quiero comenzar la demostración ahora. Lo que voy a hacer es mostrarte algo de código. Y en este código, te mostraré la aplicación. Así que esta es una simple, ya sabes, sitio web estático de Node.js. Y básicamente es solo el proyecto de ejemplo que quiero usar. Así que vamos a activar mi canalización primero. Y luego lo que vamos a hacer es en esa canalización realizar una serie de pruebas y también implementar esta aplicación en un clúster de Kubernetes, así como probar la aplicación dentro del clúster de Kubernetes que creamos utilizando infraestructura como código. Y luego eso nos dará, ¿verdad?, los buenos resultados de las pruebas de humo que necesitamos para asegurarnos de que esa versión sea de la mejor calidad posible. Hemos realizado pruebas de humo en esa implementación dentro de un clúster de Kubernetes. Así que vamos a actualizar esto a la versión 6 de la aplicación solo para activar nuestras compilaciones. Lo estoy guardando. Entonces, ahora tenemos que activar o al menos confirmar esto, ¿verdad?, en GitHub para que podamos activar nuestra compilación. Así que vamos a hacer un estado de git. Hacer un estado de git aquí. Vamos a hacer un commit de git y luego vamos a decir commit AppJS. Dale un mensaje, ¿verdad?, y luego simplemente vamos a decir número de versión actualizado. Por supuesto, necesitamos usar una m minúscula. Una vez que lo tengamos, vamos a empujar esto, empujar esto a GitHub. Así que estamos enviando nuestros cambios a nuestro repositorio compartido, ¿verdad?, que es master. Luego vamos a entrar en el panel de control de CircleCI, que básicamente muestra que hemos iniciado algunos trabajos aquí, ¿verdad?. Como puedes ver, si profundizamos en esto, este es el panel de control de CircleCI que me muestra mi compilación de canalización, ¿verdad?, y como puedes ver aquí, tengo cuatro trabajos en ejecución. Las partes más importantes aquí son este escaneo y empuje de la imagen Docker, ¿verdad?, por lo que está construyendo una imagen Docker basada en esa aplicación, y luego la creación del clúster de Kubernetes para que podamos implementar, ¿verdad?, el siguiente paso es implementar esa aplicación
9. Pruebas de Humo en Implementación de Kubernetes
Una vez que hagamos eso, la siguiente prueba será una prueba de humo de esa implementación de Kubernetes para esa aplicación. Nuestra implementación se ha desplegado utilizando infraestructura como código y nuestra canalización. Estamos realizando pruebas de humo en nuestra implementación. Probamos la aplicación para asegurarnos de que esté en funcionamiento en el contenedor Docker. Una vez que se complete la prueba de humo, el proceso de destrucción se activará automáticamente. Esto aumenta la confianza en las versiones y prueba las situaciones de implementación en el entorno objetivo. La aplicación se ejecuta sin problemas dentro de Kubernetes.
y esa imagen de
Docker a este clúster de
Kubernetes. Una vez que hagamos eso, la siguiente prueba será una prueba de humo de esa implementación de
Kubernetes para esa aplicación. Y si todas esas cosas pasan, entonces podemos pasar a un paso manual que tengo aquí, que destruirá esa infraestructura, ¿verdad? Así que este es un botón manual. Lo activamos y luego básicamente iniciaremos un trabajo de destrucción. Genial, ahora nuestra implementación se ha desplegado utilizando infraestructura como código y nuestra canalización. Y lo que sucedió aquí fue que se ejecutó nuestra prueba de humo, ¿verdad? Ahora tenemos nuestro trabajo de prueba de humo y básicamente estamos realizando pruebas de humo en nuestra implementación. Como puedes ver aquí en estos resultados, básicamente tenemos este punto final, que fue creado nuevamente por infraestructura como código y el sistema de DigitalOcean. Y vamos a probar si la aplicación realmente está en funcionamiento, ¿verdad?, en el contenedor
Docker. Y ahí está nuestra versión número seis. También tenemos este texto que estamos buscando en nuestra prueba de humo. Así que si miras aquí, obtuvimos la respuesta OK, 200. Y ahora también tenemos la prueba de aserción, que básicamente busca este texto dentro de la página web, que ciertamente tenemos. Ahora, una vez que volvemos a ver nuestra canalización, puedes ver aquí que tengo un botón para destruir esto. Ahora, nuevamente, normalmente en una canalización automática, no tendrías este paso manual. Lo tengo aquí solo con fines de demostración. Pero imagina que esto desaparecería y luego se activaría automáticamente una vez que se complete la prueba de humo. Nuevamente, esta es básicamente una forma de aumentar la confianza en tus versiones y probar tus situaciones de implementación en el entorno objetivo al que te dispongas a implementar. En este caso, implementamos en
Kubernetes. Construimos la aplicación en una imagen de
Docker, desplegamos esa imagen de
Docker y luego realizamos pruebas de humo una vez que la aplicación se desplegó. Sabemos que esta aplicación se ejecutará sin problemas dentro de
Kubernetes y eso es
Q&A Session on Smoke Testing and Depth
Espero que todos hayan aprendido algo y estoy interesado en saber qué tienen, algunos comentarios o algunas preguntas para mí, así que pasemos a la sesión de preguntas y respuestas. Lo bueno de ver aquí es que la mayoría de las personas dijeron que sí. Si eres un equipo más maduro, esto debería ser una prioridad para ti. Aprovecha algunas de estas tácticas para asegurarte de que la imagen de Docker funcione en un clúster de Kubernetes basado en la configuración que vamos a usar más adelante. Primero respondamos la pregunta de Dennis. Dennis dice, ¿cuál es un buen nivel de profundidad para una prueba de humo? Yo lo veo como flujos clave de usuarios en lugar de visitar cada página sin que se bloquee. ¿Cuál es tu definición de una prueba de humo en ese caso? Eso significará cosas diferentes para diferentes personas. Identifica los patrones que son muy importantes y críticos. ¿La aplicación devuelve un OK, 200, si es un servicio o un sitio web? Puedes realizar algunas pruebas de datos para confirmar, por ejemplo, cuando envías una solicitud de datos a tu API, realiza algunas publicaciones para asegurarte de que los datos se estén recibiendo, cosas simples y rápidas.
básicamente el punto que estoy tratando de hacer aquí. Muy bien, ese es el final de mi charla en la demostración. Espero que todos hayan aprendido algo y estoy interesado en saber qué tienen, algunos comentarios o algunas preguntas para mí, así que pasemos a la sesión de preguntas y respuestas.
Gracias, gracias. Me alegra estar aquí. Me encanta el sombrero. Excelente. Primero echemos un vistazo a los resultados. Tu pregunta fue si pruebas tus implementaciones de código en el entorno al que te diriges. Lo bueno de ver aquí es que la mayoría de las personas dijeron que sí. Sí, eso es excelente. Muy inusual, pero lo aceptaré. ¿Qué les dirías a las personas que dijeron que no están seguras? No creo que todos los equipos estén en la misma etapa, ¿verdad? Están en diferentes etapas de formación o madurez, debería decir. Así que al menos estos resultados variarán entre los equipos, pero creo que si eres un equipo más maduro, esto debería ser una prioridad para ti, ¿verdad? Y ayuda porque entiendes que tus aplicaciones están envueltas en un artefacto. Y luego, cuando implementas cosas, como dije en mi charla, el problema no es que se haya implementado en el entorno. Los problemas se descubren más tarde cuando la aplicación no se comporta como se esperaba. Y podría ser una multitud de cosas diferentes que suceden. ¿Verdad? Pero al final del día, si puedes incluir eso en la automation para tal vez un desarrollador en una etapa determinada, no diría si estás en la etapa de desarrollo o en el proceso de creación de un MVP. No introduzcas algo así en eso. Pero si vas a promoverlo a otra etapa de tu canalización, tal vez QA o algo más allá del desarrollo, entonces sí. Aprovecha algunas de estas tácticas para asegurarte de que, ¿verdad?, esta imagen de Docker funcione en un clúster de Kubernetes basado en la configuración que vamos a usar más adelante. Y simplemente se activa una casilla. De acuerdo. Sí, justo. Así que vamos a hacer algunas preguntas que tenemos de la audiencia aquí. Claro. Sí. Tenemos muchas preguntas llegando. Primero respondamos la pregunta de Dennis. Dennis dice, ¿cuál es un buen nivel de profundidad para una prueba de humo? Yo lo veo como flujos clave de usuarios en lugar de visitar cada página sin que se bloquee. ¿Cuál es tu definición de una prueba de humo en ese caso? Sí, quiero decir, eso significará cosas diferentes para diferentes personas. Así que obviamente, toma, yo diría, identifica los patterns que son muy importantes y críticos, ¿verdad? Entonces, por ejemplo, ¿la aplicación devuelve un OK, 200, si es un servicio o un sitio web, ¿verdad? Puedes realizar algunas pruebas de data para confirmar, por ejemplo, cuando envías una solicitud de data a tu API, realiza algunas publicaciones, ¿verdad?, asegúrate de que, ya sabes,
Importance of Quick Smoke Tests
Las pruebas de humo son críticas después de la implementación para asegurar que la aplicación funcione como se espera. Mantén las pruebas al mínimo, idealmente entre dos y tres minutos. Las pruebas de humo rápidas permiten realizar pruebas más exhaustivas más adelante, cuando los desarrolladores no están involucrados. El equipo de operaciones puede encargarse de las tareas de control de calidad.
Es importante asegurarse de que los datos se estén recibiendo, ya sabes, cosas simples y rápidas como esas. Pero son críticas porque si no puedes hacer ninguna de esas cosas después de la implementación, es basura, ¿verdad?, como si tuvieras una implementación contaminada. Así que ese es el ámbito y puedes profundizar tanto como quieras. Pero diría que te mantengas dentro de los límites, ya sabes, mantén tus pruebas al mínimo, como máximo dos o tres minutos. Así que hay un factor de tiempo para mí. Me gusta que todos mis trabajos, todos mis trabajos, duren menos de 60 segundos, si es posible. Sé que no es realista, pero ese es mi objetivo personal para cualquier tipo de trabajo dentro de mi canalización de
CI/
CD. Así que si estás ejecutando esa prueba de humo, intenta que sea lo más rápida posible. Porque más adelante deberías tener pruebas más exhaustivas, ya sabes, cuando los desarrolladores no están involucrados, ¿verdad? El equipo de operaciones puede encargarse de eso, ya sabes, cosas tipo control de calidad, lo que sea. De acuerdo. Tiene mucho sentido. Tenemos una pregunta de Ricardo. Ricardo dice, para mí, esta definición de las pruebas de humo es un poco diferente a lo que entiendo. Siempre tuve la impresión de que las pruebas de humo existen para verificar que las partes marcadas como críticas en tu aplicación estén funcionando. Esto significa que debería, por ejemplo, verificar un artículo, conectarse a un servicio, realizar un pago y enviar correos electrónicos de verificación. Si lo comparamos con las pruebas unitarias, no son tan rápidas. ¿Cómo lo ves tú? Sí, para mí, las pruebas de humo son simplemente una versión más rápida de tus pruebas unitarias. Estoy de acuerdo con Ricardo al 100%. Estás verificando las partes críticas de tu aplicación, como mencioné anteriormente. Sí, Ricardo. Las dividí un poco. Me gusta separarlas como diferentes, pero, nuevamente, para mí, son una versión más rápida de tus pruebas unitarias. No son tan exhaustivas. Una prueba unitaria puede ser exhaustiva, dependiendo de las características que estés probando o la funcionalidad. Nuevamente, con las pruebas de humo, es un proceso de entrar y salir. Está limitado en alcance, al igual que una prueba unitaria, pero creo que es aún más restrictivo y, en cierto sentido, más enfocado. Sí. ¿Una prueba de humo se conectaría con elementos externos, como mencionó Ricardo, como enviar correos electrónicos o conectarse a un servicio? De acuerdo, ¿entonces te basarías en dependencias externas incluso con las pruebas de humo? Claro, claro. Por supuesto, pero hazlas rápidas, ¿verdad? En una prueba unitaria, diría que te darías tal vez, dije que una prueba de humo espera entre uno y tres minutos. Una prueba unitaria, diría que te darías tal vez entre tres y cinco minutos de velocidad o prueba allí. Cualquier cosa más que eso, creo que estás entrando en una prueba de regresión integral de extremo a extremo. Pero sí, puedes probar lo que quieras con las pruebas de humo. Solo diría que te mantengas enfocado, súper, súper enfocado. Entendido. Lo tienes. Lo tienes.
React Summit 2023
Comments