¿Alguna vez has ejecutado código en CI/CD y los builds pasan solo para fallar durante la implementación? Esta presentación discutirá las ventajas de los patrones de Pruebas de Humo en los pipelines de CI/CD utilizando Infraestructura como Código (IaC). Aprende cómo los equipos pueden aprovechar la automatización para asegurarse de que las aplicaciones sean probadas en vivo en los entornos objetivo, lo cual proporciona información valiosa antes de la implementación. Angel demostrará cómo aprovechar IaC para aprovisionar infraestructura, implementar aplicaciones, probarlas y luego destruir todos los recursos creados en una sola ejecución del pipeline de CI/CD.
This talk has been presented at DevOps.js Conf 2021, check out the latest edition of this JavaScript Conference.
FAQ
CICD se refiere a la integración continua y la implementación continua, prácticas que permiten colaborar en código y automatizar pruebas y despliegues. Estas prácticas aumentan la confianza en las aplicaciones asegurando que los cambios de código se integren y se desplieguen de manera eficiente y confiable.
Se discuten varios tipos de pruebas, incluyendo pruebas unitarias, de humo, de integración funcional y de regresión. Estas pruebas varían en alcance y complejidad, desde pruebas rápidas y enfocadas hasta pruebas más integrales y costosas.
Las pruebas de humo son rápidas y tienen un alcance limitado, diseñadas para detectar fallos críticos y asegurar que las funcionalidades claves de la aplicación funcionan como se espera. Ayudan a identificar problemas rápidamente antes de proceder a pruebas más exhaustivas.
Utilizando CICD e infraestructura como código, se puede automatizar la creación de entornos de prueba, realizar pruebas de humo y luego destruir los entornos una vez validados los cambios. Esto permite verificar la integridad de las implementaciones en entornos similares a los de producción, reduciendo así las implementaciones fallidas.
Se recomienda que los equipos más maduros hagan de las pruebas en el entorno objetivo una prioridad, ya que esto ayuda a identificar problemas que pueden no ser evidentes durante las etapas de desarrollo, asegurando que la aplicación se comporta como se espera en su entorno de funcionamiento real.
Los aprendizajes clave incluyen la importancia de las pruebas de humo para detectar fallos rápidamente, la utilidad de CICD e infraestructura como código para automatizar y verificar despliegues, y la necesidad de probar aplicaciones en entornos similares a los de producción para garantizar su correcto funcionamiento.
La charla discute cómo aumentar la confianza en la aplicación utilizando CI/CD e infraestructura como código. Explora diferentes tipos de pruebas, incluyendo pruebas de humo, y los beneficios de la implementación continua. Se identifican las razones comunes de fallas posteriores a la implementación y se enfatiza la importancia de las pruebas de humo rápidas. La charla también destaca el uso de infraestructura como código para implementar y probar aplicaciones, y el valor de las pruebas de humo en implementaciones de Kubernetes. La sesión de preguntas y respuestas cubre la profundidad de las pruebas de humo y el papel de las pruebas de humo rápidas en garantizar la funcionalidad de la aplicación.
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
Short description:
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
Short description:
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
Short description:
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
Short description:
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
Short description:
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
Short description:
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
Short description:
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
Short description:
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
QnA
Q&A Session on Smoke Testing and Depth
Short description:
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
Short description:
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.
NPM workspaces help manage multiple nested packages within a single top-level package, improving since the release of NPM CLI 7.0. You can easily add dependencies to workspaces and handle duplications. Running scripts and orchestration in a monorepo is made easier with NPM workspaces. The npm pkg command is useful for setting and retrieving keys and values from package.json files. NPM workspaces offer benefits compared to Lerna and future plans include better workspace linking and adding missing features.
We will learn how to automate code and testing with GitHub Actions, including linting, formatting, testing, and deployments. Automating deployments with scripts and Git hooks can help avoid mistakes. Popular CI-CD frameworks like Jenkins offer powerful orchestration but can be challenging to work with. GitHub Actions are flexible and approachable, allowing for environment setup, testing, deployment, and custom actions. A custom AppleTools Eyes GitHub action simplifies visual testing. Other examples include automating content reminders for sharing old content and tutorials.
DevOps is a journey that varies for each company, and remote work makes transformation challenging. Pull requests can be frustrating and slow, but success stories like Mateo Colia's company show the benefits of deploying every day. Challenges with tools and vulnerabilities require careful consideration and prioritization. Investing in documentation and people is important for efficient workflows and team growth. Trust is more important than excessive control when deploying to production.
Slow CI has a negative impact on productivity and finances. Debugging CI workflows and tool slowness is even worse. Dependencies impact CI and waiting for NPM or YARN is frustrating. The ideal CI job involves native programs for static jobs and lightweight environments for dynamic jobs. Improving formatter performance and linting is a priority. Performance optimization and fast tools are essential for CI and developers using slower hardware.
Today's Talk discusses rethinking CI in monorepos, with a focus on leveraging the implicit graph of project dependencies to optimize build times and manage complexity. The use of NX Replay and NX Agents is highlighted as a way to enhance CI efficiency by caching previous computations and distributing tasks across multiple machines. Fine-grained distribution and flakiness detection are discussed as methods to improve distribution efficiency and ensure a clean setup. Enabling distribution with NX Agents simplifies the setup process, and NX Cloud offers dynamic scaling and cost reduction. Overall, the Talk explores strategies to improve the scalability and efficiency of CI pipelines in monorepos.
Let's talk about React and TypeScript, Yarn's philosophy and long-term relevance, stability and error handling in Yarn, Yarn's behavior and open source sustainability, investing in maintenance and future contributors, contributing to the JavaScript ecosystem, open-source contribution experience, maintaining naming consistency in large projects, version consistency and strictness in Yarn, and Yarn 4 experiments for performance improvement.
Desplegar aplicaciones React Native manualmente en una máquina local puede ser complejo. Las diferencias entre Android e iOS requieren que los desarrolladores utilicen herramientas y procesos específicos para cada plataforma, incluidos los requisitos de hardware para iOS. Los despliegues manuales también dificultan la gestión de las credenciales de firma, las configuraciones de entorno, el seguimiento de las versiones y la colaboración en equipo. Appflow es la plataforma de DevOps móvil en la nube creada por Ionic. Utilizar un servicio como Appflow para construir aplicaciones React Native no solo proporciona acceso a potentes recursos informáticos, sino que también simplifica el proceso de despliegue al proporcionar un entorno centralizado para gestionar y distribuir tu aplicación en múltiples plataformas. Esto puede ahorrar tiempo y recursos, permitir la colaboración, así como mejorar la confiabilidad y escalabilidad general de una aplicación. En este masterclass, desplegarás una aplicación React Native para su entrega en dispositivos de prueba Android e iOS utilizando Appflow. También aprenderás los pasos para publicar en Google Play y Apple App Stores. No se requiere experiencia previa en el despliegue de aplicaciones nativas, y obtendrás una comprensión más profunda del proceso de despliegue móvil y las mejores prácticas para utilizar una plataforma de DevOps móvil en la nube para enviar rápidamente a gran escala.
Walt te mostrará 2 formas de crear rápidamente un sitio web en Vultr: desde cero utilizando archivos HTML y CSS con Object Storage, y con el Marketplace de 1 clic de Vultr.
Desplegar y gestionar aplicaciones JavaScript en Kubernetes puede volverse complicado. Especialmente cuando una base de datos también debe formar parte del despliegue. MongoDB Atlas ha facilitado mucho la vida de los desarrolladores, sin embargo, ¿cómo se integra un producto SaaS con su clúster de Kubernetes existente? Aquí es donde entra en juego el Operador de MongoDB Atlas. En este masterclass, los asistentes aprenderán cómo crear una aplicación MERN (MongoDB, Express, React, Node.js) localmente y cómo desplegar todo en un clúster de Kubernetes con el Operador de Atlas.
Las Azure Static Web Apps se lanzaron a principios de 2021 y, de forma predeterminada, pueden integrar su repositorio existente y implementar su aplicación web estática desde Azure DevOps. Este masterclass demuestra cómo publicar una Azure Static Web App con Azure DevOps.
Cómo desarrollar, construir e implementar microservicios Node.js con Pulumi y Azure DevOps
Workshop
2 authors
El masterclass ofrece una perspectiva práctica de los principios clave necesarios para desarrollar, construir y mantener un conjunto de microservicios en el stack Node.js. Cubre los detalles específicos de la creación de servicios TypeScript aislados utilizando el enfoque de monorepo con lerna y yarn workspaces. El masterclass incluye una descripción general y un ejercicio en vivo para crear un entorno en la nube con el framework Pulumi y los servicios de Azure. Las sesiones están dirigidas a los mejores desarrolladores que deseen aprender y practicar técnicas de construcción e implementación utilizando el stack Azure y Pulumi para Node.js.
Comments