La automatización de una única aplicación monolítica es bastante sencilla. Divídela en una parte frontal y una parte trasera y aún es manejable. Agrega más componentes o infraestructura y de repente te estarás rascando la cabeza preguntándote por qué se ejecutó o no se ejecutó una compilación. ¿Cuántos pipelines necesito? ¿Cuántos repositorios de git debería tener? Vamos a revisar casos de uso desde equipos pequeños que poseen toda su pila hasta organizaciones con unidades de TI centralizadas que administran infraestructura compartida. Aprende qué escenarios y criterios determinan cómo dividir pero no convertir en espagueti tus pipelines.
Infra vs Apps: ¿Dónde están mis Pipelines?
FAQ
CICD se refiere a la integración continua y la entrega continua, un método para entregar aplicaciones e infraestructura de manera eficiente y segura a través de la automatización en las fases de desarrollo, prueba y producción.
Julie ha trabajado como ingeniera full-stack, Arquitecta Empresarial en Allianz Alemania y actualmente es ingeniera en Microsoft, formando parte del programa Fast Track para Azure.
Julie prefiere Jenkins porque lo considera su servidor de compilación favorito, a pesar de también utilizar Azure DevOps y GitHub Actions.
En el contexto de CICD, las aplicaciones monolíticas pueden ser manejadas mediante un mono repositorio, donde los cambios se empujan a la rama principal y se implementan automáticamente en el entorno de producción utilizando herramientas como Jenkins.
Julie destaca que al dividir una aplicación, como separar el backend del frontend, surge la confusión sobre qué componente implementar y cómo manejar múltiples componentes y disparadores en el sistema CICD.
Las pruebas de extremo a extremo son críticas en CICD para asegurar que las aplicaciones funcionen como se espera antes de su despliegue en producción, ya que permiten verificar la funcionalidad completa del sistema.
Julie menciona que Kubernetes puede complicar el proceso de CICD debido a su enfoque en la infraestructura, que incluye manejar múltiples almacenes de datos y configuraciones de enrutamiento, lo que aumenta la complejidad y los puntos de fallo potenciales.
Julie enfatiza la coordinación entre equipos y la importancia de la comunicación efectiva para manejar la complejidad en CICD, especialmente en grandes organizaciones donde los equipos deben trabajar juntos para resolver problemas y mejorar procesos.
Video Summary and Transcription
1. Introducción a CICD y Mi Experiencia
Hola, mi nombre es Julie. Soy ingeniera en Microsoft y hoy voy a hablarles sobre CICD y cómo funciona todo, y cómo funciona cuando tienes aplicaciones e infraestructura. Formo parte del programa Fast Track para Azure, lo que significa que ayudo a incorporar a los clientes a Azure. Antes de eso, fui Arquitecta Empresarial en Allianz Alemania, que es una compañía de seguros multimillonaria, y en realidad muchas de las opiniones y recomendaciones que les voy a dar hoy provienen de esa experiencia, así como de mi experiencia en Microsoft. Vengo del mundo Mac, de código abierto. Me gusta Node.js, Ruby, realmente no me gusta Windows. Soy una persona muy opinativa, así que trataré de mencionar cuando algo es mi opinión personal y recomendación. La foto que puse aquí es nostálgica porque fue literalmente la última semana de febrero antes del confinamiento debido a la Corona. Así que se siente muy extraño no solo trabajar de forma remota sin haber conocido nunca a tus colegas, sino también dar una charla en este momento a través de video. Pero parece funcionar.
Hola, mi nombre es Julie. Soy ingeniera en Microsoft y hoy voy a hablarles sobre CICD y cómo funciona todo, y cómo funciona cuando tienes aplicaciones e infraestructura.
Así que un poco sobre mí. Como dije, soy ingeniera en Microsoft. Formo parte del programa Fast Track para Azure, lo que significa que ayudo a incorporar a los clientes a Azure. Antes de eso, fui Arquitecta Empresarial en Allianz Alemania, que es una compañía de seguros multimillonaria, y en realidad muchas de las opiniones y recomendaciones que les voy a dar hoy provienen de esa experiencia, así como de mi experiencia en Microsoft. Antes de eso, fui ingeniera full-stack, y todavía lo soy, y diseñadora.
Así que vengo del mundo Mac, de código abierto. Me gusta Node.js, Ruby, realmente no me gusta Windows. Soy una persona muy opinativa, así que trataré de mencionar cuando algo es mi opinión personal y recomendación. La foto que puse aquí es nostálgica porque fue literalmente la última semana de febrero antes del confinamiento debido a la Corona. Así que se siente muy extraño no solo trabajar de forma remota sin haber conocido nunca a tus colegas, sino también dar una charla en este momento a través de video. Pero parece funcionar.
2. CICD Use Cases and Mono Repo with Jenkins
Hoy les voy a presentar varios casos de uso para CICD. Comencemos con un mono repositorio y Jenkins como servidor de compilación. Después de hacer un push a la rama principal, Jenkins implementa en el entorno de producción. Para asegurarnos de que funcione, necesitamos entrega continua y promoción automatizada. Ejecutar pruebas de extremo a extremo en la aplicación implementada ayuda a verificar su funcionalidad. Si las pruebas fallan, el trabajo se detiene. Si pasan, Jenkins realiza los cambios en la rama de producción, lo que desencadena otro trabajo para implementarlo.
De acuerdo, comencemos con un ejemplo muy simple. Hoy les voy a presentar varios casos de uso. Voy a intentar empezar de forma sencilla, y luego se vuelve realmente complicado muy rápidamente, pero la idea es enseñarles a pescar, y no darles un pez, cuando se trata de descubrir CICD por ustedes mismos.
Así que empecemos con lo más fácil posible, ¿verdad? Un mono repositorio, porque venimos de los monolitos. Muy simple. Voy a hacer un push y un servidor de compilación lo recogerá. Así que aquí tengo Jenkins. Jenkins es mi servidor de compilación favorito de todos los tiempos. Sí, también uso Azure DevOps y GitHub Actions, pero aún prefiero Jenkins.
De todos modos, digamos que hago un push a la rama principal. Se implementará en mi entorno de producción. Digamos que eventualmente estoy satisfecho. De alguna manera, en mi computadora local, hago cambios sin piedad en producción, y luego hago push de los cambios a producción y Jenkins los implementa en mi entorno de producción. Todo está bien, creo. ¿Cómo sabes que realmente funciona? Sabes, como ese tipo de CI que simplemente va allí. Hace algunas tareas. Pero ¿realmente funciona? ¿Cómo llegas al punto de la entrega continua? ¿Puedes hacer promoción automatizada? Eso es un poco más complicado de lo que muchas personas esperan cuando lo hacen por primera vez.
Entonces, todavía tenemos el mismo mono repositorio, la misma especie de aplicación monolítica. Vamos a hacer un push a nuestra rama principal, que recuerden, corresponde a nuestro entorno de desarrollo. Jenkins lo habrá implementado. Todo está listo. Ejecutemos algunas pruebas de extremo a extremo. Así que en este ejemplo teórico, digamos que tengo una aplicación de una sola página que en realidad tiene un conjunto de pruebas de extremo a extremo, que abrirá un navegador, hará clic en todo. Y lo que mi usuario final intenta hacer en la aplicación, podemos verificar que funcione como se espera. Así que tal vez pueda comprar una camiseta, por ejemplo. Según los resultados de esa prueba, si no funcionan, entonces decimos, oh, falló, fin del trabajo, fin de la historia, fin del trabajo de compilación, eso es. Digamos que realmente funciona. Lo que puedes hacer es hacer que Jenkins haga ese commit por ti en esa rama de producción. Mientras antes, tal vez hayas hecho clic en todo manualmente para asegurarte de que funcione, ahora puedes ejecutar un conjunto de pruebas de extremo a extremo y decir, okay, tengo confianza, implementémoslo en producción, lo que iniciará otro trabajo, y luego lo implementaremos en producción.
QnA
Check out more articles and videos
We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career
Workshops on related topic
En este masterclass, los participantes serán introducidos a los fundamentos básicos de la Integración Continua y Entrega/Despliegue Continuo. Los participantes aprenderán los principios fundamentales de CI/CD y tendrán la oportunidad de reforzar lo que han aprendido en un taller práctico con la plataforma CircleCI. El taller demostrará la configuración de construcción de CI/CD, confirmaciones de código, construcción de confirmaciones, pruebas de código y empaquetado. Los participantes se irán con una experiencia práctica y comprensión de lo que implica CI/CD.
Tabla de contenidos- Introducción al tema de CI/CD y motivación para ello- Cómo se construyen y despliegan diferentes tipos de proyectos JavaScript (desde sitios estáticos hasta APIs)- Resumen de los pasos manuales comunes y cómo podríamos automatizarlos- Implementación de un pipeline de CI/CD desde cero- Resumen de los orbs de CircleCI- Pruebas en múltiples versiones de Node- Depuración de construcciones con SSH- Caché de dependencias- Seguridad / escaneo de vulnerabilidades- Despliegue en diferentes salidas
Requisitos previos- Código y git instalados- Cuenta de GitHub
github.com/CircleCI-Public/cicd-workshop-js
Comments