Éxito de CI/CD para Desarrolladores de Vue

De todos modos, todo ha sido probado, todo está listo. Solo está esperando que presiones ese gran botón rojo, que luego inicia el proceso de implementación y pone el software en manos de tus usuarios. Entonces, sin más preámbulos, presionas ese gran botón rojo. Tiene un agradable clic audible. Es muy satisfactorio, con una agradable retroalimentación táctil. Como solo puede tener un buen teclado mecánico. Y luego comienza la carrera. El software está fuera de tus manos y se está implementando. Y en cuestión de minutos, tal vez horas, dependiendo de lo que estés implementando y cómo se haga, este software será utilizado por tus usuarios. Y todo lo que puedes hacer es contener la respiración y quedarte en silencio.

Y luego tienes dos opciones. Opción uno. Sigues conteniendo la respiración, sudando, y esperando nerviosamente a que comience a explotar, que aparezcan algunos errores y tus usuarios se quejen. Opción B, empacas y te vas a casa, porque son las 4 pm de un viernes y has hecho tu trabajo. Yo ciertamente prefiero la opción B, en parte porque son las 4 pm de un viernes cuando estoy grabando esto, pero también porque es algo más agradable de hacer si quieres disfrutar de tu fin de semana. De todos modos, la diferencia entre las dos, sin embargo, siempre se reduce a la automatización, y siempre se reduce a la automatización, desde el software hasta los procesos, la fabricación, y sí, también la agricultura. Bueno, hoy no hablaremos de agricultura. Me gusta comparar el ciclo de vida de entrega de software con el proceso de cultivar y cuidar cultivos. Entonces, si imaginas que tienes un campo como este, puedes tener cientos de personas trabajando en ese campo, plantando todo, recogiendo todo manualmente, regando, deshierbando, todas esas cosas. Haciéndolo manualmente con cientos de personas, cumple con el objetivo, pero no es tan reproducible como uno quisiera.

Por supuesto, puedes hacerlo con muchas menos personas si utilizas algunos tractores, si implementas sistemas de riego o llevas esto unos cuantos pasos más allá y pones todo en un invernadero con atmósfera controlada, iluminación controlada, nutrientes controlados que se alimentan directamente a cada planta individual, y me gusta imaginar que estas manos robóticas utilizan la visión por computadora para recoger las plantas en su mejor madurez para venderlas óptimamente. Y eso es a lo que me gusta comparar un sistema de CI-CD realmente ajustado.

Todo está automatizado. Todo está fuera de tus manos y las cosas simplemente funcionan. Hasta que, por supuesto, no lo hacen. Y aunque no espero que tu sistema de CI-CD y los robots en un invernadero se levanten de repente y se conviertan en dinosaurios que intenten matarnos a todos, definitivamente pueden A, arruinar tus cultivos, y B, tu sistema de CI-CD definitivamente puede arruinarte el día si has implementado algo que no es realmente desplegable. Pero no te preocupes. Nunca es culpa de la máquina. Siempre somos nosotros, ya sabes. Siempre somos los humanos que programamos estas máquinas, y es nuestra culpa romper las cosas.

Y con ese pensamiento en mente, mi nombre es En Marken. Soy un defensor del desarrollo en CircleCI y rompo muchas cosas. Y a menudo soy el problema entre el teclado y la silla. Esta charla se titula Éxito de CI-CD con Vue.js y para desarrolladores de Vue.js. Pero los consejos y trucos que estoy compartiendo aquí son esencialmente universales para todos los sistemas de CI-CD, para todos los lenguajes de programación, sin importar lo que estés construyendo o cómo lo estés haciendo. La mayoría de las cosas siempre serán ciertas. Como mencioné, trabajo para CircleCI. Hemos estado aquí durante 10 años. Somos el proveedor líder mundial de CI-CD y un gran número de equipos de todo el mundo que trabajan en muchas plataformas diferentes, lenguajes de programación y paradigmas de programación nos utilizan, incluyendo partes de Vue.js también, lo cual es realmente genial poder hablarles sobre esto ahora. Así que sí, esto no es para hablar de CircleCI. Esta es una charla sobre las mejores prácticas, optimización, consejos y trucos de CI-CD en general para ayudarte a aprovechar al máximo. Pero como estamos hablando de CI-CD, ¿qué significa realmente? ¿Qué significa en realidad?

Entonces, es un doble acrónimo donde CI significa integración continua. Esta es la práctica de construir y probar automáticamente todos los cambios a medida que se envían a repositorios remotos por parte de los desarrolladores. Así que si estás trabajando en un proyecto de GitHub con un equipo, cada vez que haces un commit, el proceso de CI ejecutará esencialmente todas tus pruebas, realizará todas las verificaciones que puedas tener, como el escaneo de seguridad, análisis de código estático y, en última instancia, producirá una aplicación construida. Además de que esto sucede automáticamente, todo también ocurre en aislamiento. Ahí es donde viene la analogía del invernadero. Porque todas las construcciones, todas las pruebas se ejecutan en máquinas virtuales o contenedores Docker, que se crean desde cero. Simplemente especificas el tipo de entorno que deseas y luego todos los pasos necesarios. Todo también está configurado con un archivo de configuración que se encuentra dentro del mismo repositorio, en CircleCI usamos YAML, pero podrías usar cualquier otro formato para eso. Pero en última instancia, sí, codificas, todo está vinculado al mismo commit y todo es reproducible.

Esa es la parte de CI. Pero ahora que tenemos nuestra aplicación construida y probada y lista para el horario estelar con los usuarios también queremos implementarla. Y CD es la parte de eso que realmente hace la implementación. Y, sí, no importa en qué entorno estés implementando, podría ser un entorno de vista previa para tu aplicación Vue o podría ser un clúster de producción de Kubernetes al que estás tratando de llevar este software o cualquier otra cosa en el medio, en realidad.

Pero, sí, el paso de implementación continua es eso. Y como puedes imaginar, todo este asunto de CI-CD tiene muchas dimensiones de las que esencialmente debemos estar al tanto, debemos pensar en ellas, debemos ocuparnos de ellas para tener éxito. Y, sí, debemos tener éxito en cada una de ellas porque cada una de ellas realmente puede frenarte y evitar que disfrutes desarrollando algo. Así que, sí, en esta charla, desentrañaremos algunas de esas dimensiones y, sí, las desglosaremos y hablaremos de consejos y trucos para ello.

La primera, probablemente la dimensión más obvia en la que podemos pensar es la velocidad. ¿Qué tan rápido se ejecuta tu canal de CI-CD? Eso es lo más obvio en lo que puedes pensar, especialmente si los desarrolladores confían en tu CI para decirles si su trabajo está pasando todas las pruebas, es exitoso. Tan pronto como puedas proporcionarles esa información, mejor, porque pueden continuar su trabajo, pero hay más en la velocidad, mucho, mucho más en la velocidad. El otro podría ser el tiempo de recuperación de una compilación fallida. Si estás pensando que si estás trabajando en una rama principal y fusionas algo que no pasa la compilación, entonces, la compilación esencialmente se vuelve roja en lugar de verde, quieres que vuelva a ser verde, que vuelva a pasar lo más rápido posible porque tu rama principal es esencialmente donde puedes implementar todas las actualizaciones para tus usuarios, para tus probadores, para tus interesados. Así que, sí, esa es otra faceta muy importante de la velocidad.

Y luego hay consideraciones de velocidad organizativa, como el tiempo para lanzar una función, cuánto tiempo necesita mi equipo desde que recibe un mandato de un gerente de productos para una nueva función hasta que realmente la implementa para los usuarios. CI definitivamente puede ayudarte a construir eso de manera continua y obviamente CD definitivamente puede ayudarte a llevar eso a los usuarios tan pronto como sea posible, tan pronto como esté listo, y, sí, todas las actualizaciones también. Y por último, hay cosas en las que quizás no pienses en términos de velocidad, pero podrían ayudarte a integrar nuevos miembros del equipo porque, como dije, todo está configurado en código, todos pueden leer YAML, con suerte. Entonces, un nuevo miembro del equipo puede simplemente señalar esta configuración de CI/CD y decir, `estos son los entornos, todo, todos los trabajos que estamos haciendo, todos los diferentes tipos de pruebas. Tal vez estés haciendo pruebas unitarias, tal vez estés haciendo pruebas de integración, tal vez estés iniciando algunas pruebas de humo también. Tal vez estés haciendo un despliegue canario, como un tipo de despliegue realmente avanzado, y un nuevo miembro del equipo puede entender lo que está sucediendo y luego hacerte preguntas sobre porciones individuales de esa canalización esencialmente automatizada, lo cual es hermoso. De todos modos, velocidad. Ejecutar las cosas más rápido. Lo primero que debes hacer es realmente pensar si estás ejecutando las cosas en el tamaño correcto de máquinas. Entonces, tienes una computadora portátil de desarrollo y probablemente tenga una cierta cantidad de gigabytes de RAM, una cierta cantidad de procesadores virtuales o hilos con los que puedes trabajar. Y si tu computadora portátil está construyendo algo en un minuto y tu CI tarda cinco minutos, tal vez tu CI necesite más recursos para acelerar más, literalmente, para que funcione más rápidamente. El segundo son cosas como la caché. Por ejemplo, la caché es simplemente reutilizar cosas que ya has hecho. Por ejemplo, los módulos de node, has ejecutado npm install una vez, tal vez si tu package.json no ha cambiado realmente, tal vez eso sea suficiente por ahora, no necesitas actualizar todas las dependencias. Tal vez solo puedas almacenarlas y extraerlas de la caché la próxima vez para no tener que cargarlas en cada momento individual. Tal vez estés utilizando algunas técnicas de almacenamiento en caché avanzadas, técnicas de pruebas con algunas utilidades de pruebas, y para eso tal vez no quieras instalar todo en tu contenedor Docker, tal vez puedas usar una imagen de Docker que ya tenga todo eso preinstalado.

Estas son todas las cosas que puedes almacenar en caché y realmente ayudarte a acelerar todo el proceso en muchas ejecuciones. Hablando de ejecuciones, los propios trabajos, como la construcción, testing, varios tipos de testing también se pueden ejecutar en paralelo. Y también se pueden dividir, especialmente si tienes una suite de pruebas de integración de larga duración o muchas pruebas funcionales que abarcan diferentes partes de tu aplicación como lo haría un usuario. Puedes dividir esas pruebas dentro de una sola suite de pruebas en múltiples trabajos de prueba paralelos, que esencialmente ejecutan solo una parte de eso, lo que obviamente reduce significativamente el tiempo.

Y, por supuesto, puedes elegir qué se ejecuta cuando quieras ejecutarlo. Por ejemplo, tal vez, sí, quieres ejecutar tus pruebas, tal vez quieres ejecutar algunas pruebas funcionales, pero no necesitas ejecutar todas ellas. Solo necesitas hacer esa parte mínima y luego hacer esa implementación previa de tu sitio web, que es suficiente para la mayoría de los casos de uso. Pero luego, cuando estés listo para fusionar esto en la rama principal, prepararte para un lanzamiento, quieres ejecutar todas las pruebas.

Entonces, esa es la velocidad en general. Pero, ¿qué pasa cuando las cosas no salen como se planean? A veces simplemente rompes las cosas. Para eso, realmente quieres recuperarte de las fallas mucho más rápido. El primero es comprender qué está sucediendo en tus compilaciones. Como registrar todo, poder obtener esos registros. Esto depende de tus frameworks, de tus herramientas. Pero realmente invierte tiempo en comprenderlos, comprender cómo leer los registros, cómo obtener esa información y aprovechar al máximo tu CI-CD. Porque hay información ahí dentro.

Y mi cosa favorita es poder debug tus compilaciones cuando fallan. A veces tu entorno fallará, algo en tu entorno fallará. Con CircleCI, por ejemplo, tenemos esta función genial llamada SSH debug. Entonces, básicamente, te conectas por SSH a ese entorno y puedes ver qué está sucediendo cuando tus pruebas han fallado. Tal vez haya algo mal con el estado. Tal vez haya algo mal con la database a la que te estás conectando. Y realmente te ayuda a debug rápidamente las cosas. Pero sí, la velocidad está bien. Todos estamos tratando de ir lo más rápido posible. Pero sabes qué, no es una carrera. Es muy importante, pero sí, no es una carrera. Y la velocidad de CI-CD debería verse más como una ambulancia. Así que definitivamente debería ir rápido, pero aún mantener esa carga, mantener esa señal viva. Entonces, la señal significa la calidad de tu aplicación que te dice, eh, todas mis pruebas han pasado o algunas han fallado.

Y sí, obviamente cuando las luces rojas están parpadeando, cuando la compilación está en rojo en tu rama principal, arréglalo lo antes posible. No lo dejes esperando. De todos modos, esa velocidad.

Ahora, pensemos en algunas otras cosas como security, algo que realmente puede ralentizarte mientras estás construyendo cosas. Como muchos de ustedes probablemente saben, sí, una revisión de security definitivamente puede ralentizarte. Pero también hay formas de controlar la security con un sistema CI/CD. El primero y más importante es mantener las credenciales dentro del sistema CI/CD y utilizarlo para afinar tus políticas de control de acceso y permitir solo a quienes tienen los permisos adecuados enviar o implementar en un entorno específico o simplemente mantener las credenciales fuera de tus repositorios de Git, al menos. Eso es algo que puedes hacer. Y el siguiente es automatizar el escaneo de security. Sabes lo vulnerables que son, lo fácil que es introducir una biblioteca vulnerable o incluso comprometida en tu aplicación y existen herramientas disponibles que se integran en tu flujo CI/CD y automatizan todo eso por ti para que no estés filtrando los números de tarjeta de crédito o los números de pasaporte de tus clientes desde el frontend, lo cual es horrible. Entonces, sí, estas son las cosas en las que puedes pensar cuando piensas en la security.

Pero sí, hay más en el ecosistema que solo el sistema CI/CD y hay características más allá de la herramienta CI/CD. Primero, obviamente, están las características incorporadas, ¿hay algo disponible que no estás utilizando? Vale la pena leer los registros de lanzamiento, las notas de lanzamiento cada par de meses y ver, hey, tal vez han lanzado algo genial y realmente podemos utilizar esto y pensar si hay algún servicio externo que estás utilizando, tal vez herramientas de gestión de proyectos que estás utilizando que podrías integrar y simplemente vincularlo a tu flujo CI/CD e informar a todos sobre tu proceso. Y, por supuesto, nunca es una charla de DevOps si no hablamos del equipo. Y sí, mencioné que tu configuración es definitivamente una ayuda para la incorporación, pero también vale la pena reiterar que el CI/CD nunca es responsabilidad de una sola persona. Siempre es responsabilidad del equipo y lograr que todos estén a bordo para al menos comprender lo que está sucediendo, si no para poder introducir y sugerir mejoras a todo el proceso porque eso les beneficiará a todos. Y obviamente hemos iniciado la implementación al principio y a veces todo va bien, pero a veces no. Sucederán cosas que romperán algún software, romperán algunas implementaciones, y deberás volver a un estado funcional. Afortunadamente, tenemos una máquina del tiempo porque todo está vinculado a un commit. Simplemente podemos revertir a un commit anterior y reiniciar ese proceso, y tu proceso CI/CD definitivamente puede ayudarte a recuperarte mucho más rápido de lo que tendrías que... que podrías pensar en hacerlo manualmente. Y sí, otra cosa es porque estamos haciendo todas esas testing, todas estas testing, todas esas verificaciones todo el tiempo, podemos enviar cambios mucho más pequeños mucho más frecuentemente y tener lanzamientos que son mucho menos propensos a errores porque hay menos cosas que hacer. Y, sí. Lo mejor para esto es, lo mejor para prepararse es planificar y realmente prepararse y practicar para comprender, hey, hemos roto algo, ¿cómo lo recuperamos? Hagamos una prueba en seco. Implementémoslo de nuevo en el entorno de pruebas, veamos cómo funciona, cómo está preparado el equipo. En última instancia, sin embargo, para mí, tener éxito con un sistema CI/CD significa ser libre. Y ser libre significa poder entregar software en los términos que realmente controlas. Y eso es lo mejor que puedes obtener de ello. Y puedes enfocarte en la calidad, puedes enfocarte en la felicidad del equipo. Y siempre puedes adaptarte más rápido al cambio porque puedes enviar constantemente y lanzar cosas mucho más rápido de lo que lo harías sin todo el enfoque de... un enfoque de invernadero. Y sí, como beneficio tienes este proceso de compilación, prueba e implementación auto-documentado que cualquiera puede leer y utilizar y, obviamente, recuperarte de las fallas mucho más rápido porque a, todos comprenden todo el proceso y b, todo es reproducible. Mi nombre es Anne Marken. Esta fue una charla sobre el éxito con CI/CD para Vue.js. Espero que lo hayas disfrutado.