Automatizando Todo el Código y las Pruebas con GitHub Actions

Hola a todos. Vamos a aprender cómo podemos automatizar todas las cosas, todas las cosas de code y testing con GitHub Actions. Entonces, ¿quién soy yo? Soy Colby Fayok. Soy el que está abrazando a BB8 y Kylo Ren allí. Trabajo con la comunidad de desarrolladores como defensor del desarrollador para Applitools. Puedes encontrarme prácticamente en cualquier lugar de la web simplemente buscando mi nombre ya que soy el único en el mundo.

Entonces, vamos a entrar en materia. Como desarrolladores, tenemos un montón de tareas con las que tenemos que lidiar día a día. Y en particular, vamos a hablar sobre las tareas de code. Veamos cómo podrían ser algunas de estas.

Bueno, primero está el linting. El linting básicamente te dice si escribes code descuidado. Pero en serio, puede ser realmente útil para identificar errores de sintaxis. También es generalmente útil para asegurarse de que tu code parece que la misma persona lo escribió, lo que hace que tu code sea fácil de leer y también de trabajar en equipo. El problema es que, a menos que estés ejecutando algún tipo de framework moderno con él de serie, tienes que recordar ejecutarlo.

El formateo es básicamente linting, pero solucionará todos esos problemas por ti. Tu linter como eslint incluso podría hacerlo él mismo. Pero con el formateo, tienes herramientas como Prettier, donde formatearán el code e incluso incluirán una configuración con opiniones. El linting y el formateo vienen con muchos beneficios super prácticos. También te beneficias de no tener que pasar tiempo en revisiones de code donde vas a discutir sobre preferencias de sintaxis. Puedes dejar que los robots sean el malo y lo hagan por ti. Hay menos cosas en las que tienes que pensar y menos cosas por las que tienes que estresarte. Pero de nuevo, tu peor enemigo aquí es recordar ejecutarlo.

Aún más crítico para el flujo de trabajo de un desarrollador es el testing, y mientras que el formateo y el linting ayudan a prevenir errores, es más bien un análisis estático, y te ayuda a encontrar los errores de sintaxis. Pero no está haciendo mucho para probar realmente la funcionalidad. Las pruebas ayudarán a asegurarte de que no estás rompiendo cosas y terminas perdiendo dinero cuando tu tienda en línea está caída. Las pruebas no son solo para que tu ingeniero de QA las ejecute de vez en cuando. Necesitas ejecutar estas pruebas regularmente, de lo contrario, no están realmente haciendo su trabajo.

Y finalmente, la última cosa de la que hablaremos son las implementaciones. Y en última instancia, quieres que tu aplicación vaya a algún lugar para que las personas puedan usarla.

Las implementaciones pueden ser dolorosas, especialmente para infraestructuras grandes y complejas donde hay muchas piezas en movimiento. Además de esto, tienes que recordar implementar todas esas piezas y omitir un paso puede derribar el sitio de una mala manera, no solo porque estás implementando una nueva versión y tienes un poco de tiempo entre diferentes migraciones. Un tema recurrente en todas estas tareas, sin embargo, es que todas son importantes de una forma u otra. Nos ayudan a centrarnos en los verdaderos desafíos del trabajo, no en el drama en la code revisión o tropezando con otra code implementación, pero otro tema, todos requieren humanos para hacerlos.

Eso significa que son propensos a errores humanos. Y ya sea simplemente por olvidar ejecutar algo o olvidar incluir un paso en particular incluso por olvidar hacerlo en el orden correcto, ¿qué podemos hacer para evitar esos errores humanos? Bueno, podemos automatizarlo, por supuesto. Así que aprendamos cómo automatizar todas las cosas.

¿Cómo automatizamos realmente todas las cosas? Si estamos implementando algo incluso moderadamente complejo, tenemos un montón de cosas que normalmente tenemos que hacer para implementar realmente nuestro stack completo. Esos 10 comandos o botones que tienes que ejecutar cada vez que tu servidor Rails y AWS infraestructura, bueno, podemos poner eso en un script. Los scripts son probablemente la forma más sencilla de automation. Esto nos ayuda a automatizar las tareas manuales que podríamos tener que hacer. ¿Por qué no ponerlos en un script bash? O inserta tu lenguaje de scripting favorito, como Node, donde incluso puedes escribir en JavaScript si eso es lo tuyo. El objetivo es tener una lista de pasos repetibles. Y al usar ese único comando con ese script, eres capaz de hacer exactamente lo mismo cada vez. De esa manera nunca olvidas dejar nada fuera.

Pero los scripts también dependen en última instancia de algo para desencadenar eso. Si todavía es un humano, podrías olvidar ejecutar ese script en primer lugar. O si alguien está cubriendo por un día, tal vez ni siquiera saben que tienes un script para ejecutar esta configuración. Una característica que viene incorporada en Git mismo son los Git hooks. Con los Git hooks, puedes desencadenar algo en diferentes puntos del proceso de Git. Por ejemplo, puedes configurar un hook de commit, donde cada vez que realmente ejecutas un commit, tu hook se ejecutará, automatizando alguna parte de tu proceso, donde un buen ejemplo para eso es el formateo. Cada vez que alguien hace un commit, puedes configurar Prettier, u otro formateador, para que se ejecute antes de que el commit se aplique realmente. Con tus scripts existentes para ejecutar el linting y el formateo, esto se llama precommit, donde, con herramientas como Husky, puedes enganchar y gestionar todos esos Git hooks. También estamos aplicando lint staged aquí, lo que nos permite obtener la ruta de todos esos cambios que realmente obtenemos en la etapa para Git, de esa manera, cuando ejecutamos nuestro hook precommit no estamos afectando todo el árbol del repositorio, solo estamos impactando los archivos que realmente cambiaron. Pero una vez que ese script termina, esos cambios se añaden a la etapa de Git antes de que ese commit se aplique realmente. Así que cuando el commit real sucede, todo lo que Git sabe es que el code es bonito y está formateado. Todo lo que el desarrollador sabe es que hizo su trabajo, y cuando el code se sube a GitHub, parece que una sola persona lo escribió. Pero no todo tiene sentido dentro de un Git hook. No quieres ejecutar tus pruebas como un hook precommit, por ejemplo, donde eso va a ser un gran dolor para los desarrolladores. Imagina que estás trabajando en un proyecto con una gran suite de pruebas y para poder hacer un commit, tienes que ejecutar toda esa suite.

No. No. No. No. Entonces podemos llevar eso a otro nivel ejecutando procesos CI-CD. CI es integración continua. CD es implementación continua, o a veces entrega continua.

Aunque algunos equipos todavía requieren que se inicie manualmente, eso derrota un poco el propósito, donde el objetivo de CI-CD es ser automatizado dentro de tus procesos de code. Por ejemplo, si quieres enviar tus cambios a la rama principal, eso desencadena un cierto conjunto de funcionalidades. Y si envías a una rama de características, tal vez eso desencadena un conjunto diferente de funcionalidades.

Algunos frameworks populares para ejecutar estos procesos son Jenkins, Bamboo, CircleCI y Travis CI. Y dependiendo del framework, la configuración puede parecer un poco diferente. La mayoría de ellos dependen de algún tipo de configuración. Pero puedes tener varios niveles de scripting incluidos directamente, donde aquí tenemos un ejemplo simple. Y personalmente todavía tengo pesadillas de trabajar realmente con Jenkins, donde soy principalmente un ingeniero de front-end. Pero el equipo de DevOps lo juraba. Creo que es principalmente por la flexibilidad, aunque. No necesariamente la facilidad de uso.

Pero configurar CI-CD puede ser súper poderoso. Puedes tener una orquestación grande y compleja de toda tu infraestructura. ¿Necesitas implementar algunas lambdas o volcar un sitio estático en el almacenamiento? Agrega un script a tus procesos CI-CD. ¿Necesitas configurar un VPC con reglas de red estrictas? Bueno, tal vez Jenkins puede hacer eso por ti. Porque realmente estás aprovechando el scripting y la automation de ese scripting, deberías realmente ser capaz de lograr cualquier cosa que quieras. Pero como mencioné antes, soy un ingeniero de front-end y luché con Jenkins. No tenía una gran documentation para consultar. Al menos en ese momento. Y esperar a que las construcciones terminaran llevaba una eternidad. Para muchos de esos frameworks, también tienes que mantener servidores. ¿Y mencioné que soy un ingeniero de front-end? Puedo configurar un servidor de nodo, pero realmente no quiero lidiar con servidores. Los servidores son tan de la década pasada, ¿verdad? Bromas aparte, quiero algo que pueda conectar y usar fácilmente.

Algo que está cerca del resto de mi code con el que no tengo que luchar. Y después de toda esa preparación, es aquí donde entran las GitHub Actions. Las GitHub Actions son técnicamente CI/CD, pero en la práctica, se sienten mucho más accesibles. La mejor parte es que pueden ser igual de flexibles. Con las Actions, puedes comenzar configurando el entorno en el que quieres ejecutar dentro del archivo de flujo de trabajo. Puedes agregar los comandos que quieras, cuando quieras ejecutarlos, y ya estás listo.

Por ejemplo, si quisiera simplemente ejecutar algunas pruebas, puedo configurar un archivo de prueba para ejecutar en Ubuntu, o una variedad de otras opciones. Luego puedo revisar ese code donde estaré ejecutando los comandos dentro de un directorio de trabajo. Para configurar Node, puedo agregar otra Action donde especifico la versión. Incluso puedo hacer que esto se ejecute en algunas versiones diferentes de Node si quisiera, dentro del mismo flujo de trabajo. Y luego finalmente, instalo las dependencias y ejecuto las pruebas. Esto solo asegurará que tengo pruebas que se ejecutan cada vez que se realiza un cambio o si se crea una solicitud de extracción en esta instancia particular.

Mientras se ejecutan, aparecen justo en línea con el resto de esa solicitud de extracción, permitiéndote saber con solo un vistazo rápido si tus cambios propuestos realmente rompen cosas o no. Esto ayuda a obtener un gran ciclo de retroalimentación para los desarrolladores cuando, si algo no funciona, recibirán esa retroalimentación rápidamente. También podría usar GitHub actions para desplegar code. Una vez que instalo las dependencias de mi proyecto, puedo construir ese proyecto. Luego configuro mis credenciales de AWS como secretos y luego puedo sincronizar esos artefactos hasta AWS para desplegar. La AWS CLI está disponible por defecto, lo que hace que esto sea realmente simple de hacer dentro de las actions. Y esto incluye cualquier tipo de comandos con la AWS CLI. E incluso puedo usar acciones del mercado de GitHub.

Si quisiera publicar un mensaje en Slack cuando se realiza una nueva solicitud de extracción, puedo usar la acción de publicar en Slack, que puedo configurar en mi proyecto y enviar una nota directamente a Slack. Es una forma útil de automatizar esas pequeñas partes del flujo de trabajo de desarrollo. Estos últimos fueron ejemplos bastante simples, pero sirven para mostrar que con solo unas pocas líneas, realmente podemos hacer muchas cosas impresionantes. Lo genial, sin embargo, es que podemos llevar esto a otro nivel. Podemos crear nuestras propias GitHub actions personalizadas. Una vez que creas una acción personalizada de GitHub, realmente ganas la flexibilidad para hacer lo que quieras dentro de ese entorno controlado. Tienes algunas opciones diferentes como ejecutar JavaScript con Node, o incluso puedes ejecutarlo con Docker, donde obtienes la capacidad de hacer lo que quieras. Por ejemplo, si tengo una tarea común que incluye un montón de cosas complicadas, yo podría no querer tener que copiar y pegar ese pequeño fragmento en cada repositorio. Puedo configurar un script de Node y ejecutar ese script como parte de mi nueva acción. De esa manera, solo tengo que hacer esa única referencia dentro del flujo de trabajo de la acción entre todos mis diferentes proyectos.

Eso es exactamente lo que hice con mi acción de GitHub de AppleTools Eyes. Y solo para agregar un poco de contexto, Appletools es una plataforma de pruebas visuales donde cada vez que ejecutas una prueba, Eyes toma una captura de pantalla de tu sitio web o tu mobile app y la compara con AI. Para hacer eso, Appletools tiene un montón de SDKs, ya sea Chipre, como ves aquí, o Selenium Java, o realmente cualquier popular testing framework que te permite incorporar el SDK en esas pruebas existentes. Y esto ya es bastante fácil de hacer, pero quería hacerlo aún más fácil. Quería una solución donde alguien que incluso podría no tener testing configurado dentro de su proyecto pudiera incorporar esto fácilmente y obtener pruebas visuales, que es donde volvemos a la acción de GitHub de Appletools Eyes. Y por lo tanto, esta acción solo toma un fragmento donde tienes que conectar tu clave API, que se requiere cada vez que quieres ejecutar una prueba a Appletools para asegurarte de que realmente envía a tu cuenta. Y de esa manera entonces proporcionas la URL de lo que realmente quieres probar.

Una vez que esa acción realmente comienza, inicia un proceso en el que primero rastreamos esa URL que pasas. Lo hace de manera similar a lo que esperarías de Google cuando lo hace con robots para buscar con SEO, donde hace clic en el sitio, rastrea qué enlaces están disponibles en tu sitio, y lo junta todo dentro de una lista. O si ya tienes un mapa del sitio personalizado, puedes pasarlo como la URL en su lugar.

Pero para rastrear, uso un paquete llamado Sitemap Generator, donde puedo ejecutar un simple comando de nodo y puedo tener todo eso dentro de una lista de URL. Una vez que he recopilado todos los detalles del sitio y las configuraciones, puedo ejecutar Cypress directamente dentro de ese script de nodo, incluyendo esas URL del mapa del sitio como un array que paso directamente a Cypress, lo que me permite recopilar todos mis resultados que puedo usar para más tarde, como fallar la acción si las pruebas realmente fallan o generalmente trabajar con los resultados para que pueda proporcionar una mejor experiencia de desarrollador dentro del repositorio de GitHub.

Pero finalmente, Cypress ejecuta esas pruebas como lo haría normalmente, dándome mi corredor de pruebas y mis resultados para la revisión de ojos. La única diferencia es que esta vez, está recorriendo todas esas páginas para verificar el mapa del sitio, por lo que está ejecutando todas esas diferentes pruebas dinámicamente en función de las URL. Pero eso me da mi corredor de pruebas y mis resultados para esa revisión de ojos. Con esos resultados, puedo comentar directamente en la solicitud de extracción, ya sea que pasen, fallen, o si simplemente están sin resolver, dando al mantenedor del proyecto una forma fácil de saber si el código realmente introdujo un error o al menos introdujo un cambio que rompe algo. Incluso encontré una solución donde podemos conectar esto a un flujo de trabajo de Netlify existente. Si no estás familiarizado con Netlify, automáticamente desplegarán tu aplicación estática directamente desde GitHub. Y esto sucede cada vez que realmente haces un cambio en tu repositorio de GitHub rama por defecto. Pude encontrar una acción donde esperaba ese despliegue, y realmente almacenaba esa URL como salida de ese flujo de trabajo de acción. Pude tomar eso y pasarlo directamente a mi acción de AppleTools.eyes, que hizo su cosa, pasó y rastreó el sitio e hizo esa prueba visual. Pero todo el proyecto es en última instancia un script que necesito ejecutar. Donde ejecutarlo entre algunos proyectos diferentes es solo una diferencia de unos pocos parámetros de entrada. En lugar de tener que asegurarme de que mi framework de pruebas está configurado dentro de cada proyecto, junto con la instalación del SDK y la escritura de todas mis pruebas, esto lo hace realmente fácil de agregar pruebas visuales de AppleTools.eyes a cualquier proyecto con solo estas pocas líneas.

Así que también vamos a ver algunos otros ejemplos de GitHub actions que están en el mundo real. También creé una plantilla de acción de GitHub llamada recordatorio de contenido. Una cosa con la que lucho como creador de contenido y educador es simplemente recordar compartir algunos de mis contenidos y tutoriales antiguos. Así que me puse mi sombrero de desarrollador e intenté hacer algo al respecto. Construí el recordatorio de contenido como una acción de GitHub, donde es simplemente un script de Node. Pero lo que sucede es que lo ejecuto en un cron para que realmente se active dos veces al día. Con Actions, no solo puedes ejecutar en eventos de GitHub, puedes ejecutar en la misma antigua sintaxis de cron a la que estás acostumbrado a programar otras ejecuciones. Pero una vez que se ejecuta, ejecuto un script de Node, donde miro a través de algunas fuentes RSS de mi contenido, encuentro una entrada aleatoria, y me envío un correo electrónico con ese contenido empujándome a compartirlo con el mundo. Para otro caso de uso práctico, el performance es o al menos debería estar en la cima de todos las mentes al construir web apps. Lighthouse es una herramienta fantástica del equipo de Google que ayuda a medir ese performance. La acción CI de Lighthouse nos permite incorporar todo eso con las mediciones directamente en nuestros proyectos, y no es muy diferente de mi acción de Apple tools, donde podemos pasar la URL directamente dentro de la acción CI de Lighthouse. También podemos definir un presupuesto de performance, como el tamaño máximo de la página, pero cuando Lighthouse realmente se ejecuta, tomará ese presupuesto en consideración, y si encuentra algún problema, agregará anotaciones directamente dentro de GitHub, informándonos cuáles son esos problemas exactos. Para llevar las cosas al mundo real, sin embargo, Alfonzo creó el problema Tron 3000 para un hackathon de GitHub. Cada vez que se crea un nuevo problema, enviará una señal a un dispositivo IoT, y aunque no estoy realmente muy familiarizado con todo el mundo IoT, la configuración es similar a cualquier otra acción, donde hay una extensa documentation si quieres averiguar cómo configurar esto. Pero en última instancia, va a ejecutar un script que Alfonzo configuró dentro de esa acción, donde configura el cliente MQTT y envía una carga útil dependiendo del evento. Y una vez recibido, el problema Tron 3000 se activa realmente, y parpadea o se ilumina según esa configuración. Funciona bastante bien en el video. Lo incluiré en el enlace en las notas de mi charla. Y finalmente, si el último no se consideraba divertido, aquí hay un poco de algo. Donde Tim creó un juego de ajedrez community en su página de perfil de GitHub, todo alimentado por GitHub Actions. Para hacer un nuevo movimiento, cualquiera puede hacer clic en uno de los enlaces a un espacio específico, donde todo lo que está haciendo es abrir un nuevo problema con esa ubicación dentro del título. Una vez que esa acción ve la solicitud abierta, finalmente ejecuta un script de Ruby para configurar ese juego. Incluyendo realmente el análisis de ese título del problema donde realmente estás viendo dónde debería ser ese próximo movimiento. Junto con un montón de otras cosas dentro de ese script que no estoy mostrando aquí. Además, también está pasando por y actualizando ese README con el nuevo movimiento. Después de que el movimiento es realmente aceptado, aparecerá directamente en el perfil de Tim. Y si eres lo suficientemente persistente con todos tus movimientos, podría aparecer incluso en la tabla de líderes. Pero lo que hagas con las acciones, el objetivo es finalmente automatizar tanto de tu code como sea posible o todas tus tareas de code como puedas. De nuevo, deja que los robots hagan el trabajo duro y sean el malo. Dedica tu tiempo a los desafíos únicos de tu proyecto. Lo genial de las acciones, sin embargo, es que las hace muy accesibles para cualquiera para usar. Ya no me estreso cuando trabajo con flujos de trabajo de CI CD. Me encanta configurar una nueva acción y averiguar qué puedo automatizar. Me emociona tener algo que se ejecute automáticamente y que ya no tengo que hacer yo mismo y estoy seguro de que tú también lo harás. Si quieres aprender a crear tu propia acción de GitHub o si quieres una introducción rápida simplemente para empezar con las acciones, tengo un montón de recursos disponibles, incluyendo un curso de egghead y un montón de videos en YouTube. Y si quieres aprender cómo ir de principio a fin desde el design hasta una aplicación completa de Next.js, incluyendo la automatización de todas tus tareas de co-con GitHub actions, echa un vistazo a mi curso gratuito en YouTube, donde también puedes encontrarlo en FrumDesign2.dev. Y eso es todo. Si quieres aprender más o charlar sobre la charla, puedes encontrarme en todas partes como Colby Fayok. También enviaré un enlace con las cosas que has visto aquí hoy. Gracias a todos.