¿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.
Aumentar la Confianza en la Aplicación Utilizando CI/CD e Infraestructura como Código
Video Summary and Transcription
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.
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.
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.
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.
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.
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.
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.
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.
QnA
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.
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.