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

Rate this content
Bookmark

Tareas de código como linting y pruebas son piezas críticas del flujo de trabajo de un desarrollador que nos ayudan a mantenernos cuerdos, como prevenir problemas de sintaxis o estilo y fortalecer nuestra lógica empresarial principal. Hablaremos sobre cómo podemos utilizar GitHub Actions para automatizar estas tareas y ayudar a que nuestros proyectos funcionen sin problemas.

19 min
25 Oct, 2021

Video Summary and Transcription

Aprenderemos cómo automatizar el código y las pruebas con GitHub Actions, incluyendo linting, formateo, pruebas e implementaciones. La automatización de las implementaciones con scripts y ganchos de Git puede ayudar a evitar errores. Los marcos de CI-CD populares como Jenkins ofrecen una orquestación poderosa pero pueden ser difíciles de trabajar. GitHub Actions son flexibles y accesibles, permitiendo la configuración del entorno, pruebas, implementación y acciones personalizadas. Una acción personalizada de AppleTools Eyes para GitHub simplifica las pruebas visuales. Otros ejemplos incluyen la automatización de recordatorios de contenido para compartir contenido antiguo y tutoriales.

Available in English

1. Introducción a la Automatización de Código y Pruebas

Short description:

Vamos a aprender cómo automatizar el código y las pruebas con GitHub Actions. El linting ayuda a identificar errores de sintaxis y garantiza un estilo de código consistente. Las herramientas de formateo como Prettier solucionan automáticamente los problemas de código. Las pruebas son esenciales para prevenir errores y garantizar la funcionalidad. Ejecutar pruebas regularmente es crucial. Las implementaciones son necesarias para que tu aplicación sea accesible para los usuarios.

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

Así que vamos a meternos de lleno en esto. Como desarrolladores, tenemos muchas tareas con las que lidiar día a día. Y en particular, vamos a hablar sobre tareas de código. Veamos cómo podrían ser algunas de ellas.

Bueno, primero está el linting. El linting básicamente te dice si escribes código descuidado. Pero en serio, puede ser realmente útil para identificar errores de sintaxis. También es útil en general para asegurarse de que tu código parezca que lo ha escrito la misma persona , lo que hace que tu código sea fácil de leer y trabajar en equipo. El problema es que, a menos que estés utilizando algún tipo de framework moderno que lo incluya de serie, debes recordar ejecutarlo.

El formateo es básicamente linting, pero solucionará todos esos problemas por ti. Tu linter como eslint incluso puede hacerlo automáticamente. Pero con el formateo, tienes herramientas como Prettier, donde formatearán el código e incluso incluirán una configuración con opiniones. El linting y el formateo tienen muchos beneficios prácticos. También te beneficias de no tener que dedicar tiempo a revisiones de código donde discutirás sobre preferencias de sintaxis. Puedes dejar que los robots sean los malos y lo hagan por ti. Hay menos cosas en las que tienes que pensar y menos cosas de las que realmente tienes que estresarte . Pero nuevamente, tu peor enemigo aquí es recordar ejecutarlo.

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

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

2. Automatización de Implementaciones con Scripts y Git Hooks

Short description:

Las implementaciones pueden ser complejas y propensas a errores humanos. La automatización del proceso de implementación puede ayudar a evitar errores. Los scripts y los Git hooks son útiles para la automatización. Los Git hooks pueden activar acciones en diferentes puntos del proceso de Git. Por ejemplo, un Git hook previo a la confirmación puede automatizar el formateo. Lint staged permite que los cambios específicos sean afectados por el Git hook previo a la confirmación. Sin embargo, ejecutar pruebas como un Git hook previo a la confirmación puede resultar incómodo para los desarrolladores.

Las implementaciones pueden ser dolorosas, especialmente para infraestructuras grandes y complejas donde hay muchas piezas en movimiento. Además de esto, debes recordar implementar todas esas piezas y omitir un paso puede hacer que el sitio se caiga de manera desastrosa, no solo porque estás implementando una nueva versión y tienes poco tiempo entre diferentes migraciones. Un tema común en todas estas tareas 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 de la revisión del código o en tropezar con otra implementación de código, pero otro tema es que todas requieren que los humanos las realicen.

Eso significa que son propensas a errores humanos. Y ya sea simplemente olvidar ejecutar algo o olvidar incluir un paso en particular o incluso olvidar hacerlo en el orden correcto, ¿qué podemos hacer para evitar realmente 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 típicamente tenemos que hacer para implementar nuestra pila completa. Esos 10 comandos o botones que debes ejecutar cada vez que tu servidor de Rails y tu infraestructura de AWS están listos, bueno, podemos poner eso en un script. Los scripts son probablemente la forma más sencilla de automatización. Esto nos ayuda a automatizar las tareas manuales que debemos realizar. Entonces, ¿por qué no ponerlos en un script de bash? O utiliza tu lenguaje de scripting favorito, como Node, donde incluso puedes escribirlo en JavaScript si eso es lo tuyo. El objetivo es tener una lista de pasos repetibles. Y al usar ese comando con ese script, puedes hacer exactamente lo mismo cada vez. De esa manera, nunca olvidas dejar algo fuera.

Pero los scripts también dependen en última instancia de algo para activarlos. Si todavía es un humano, es posible que olvides ejecutar ese script en primer lugar. O si alguien te reemplaza por un día, es posible que ni siquiera sepan que tienes un script para ejecutar esta configuración. Una característica incorporada en Git son los Git hooks. Con los Git hooks, puedes activar algo en diferentes puntos del proceso de Git. Por ejemplo, puedes configurar un hook de confirmación, donde cada vez que realizas una confirmación, se ejecutará tu hook, automatizando alguna parte de tu proceso, donde un buen ejemplo de eso es el formateo. Cada vez que alguien realiza una confirmación, puedes configurar Prettier u otro formateador para que se ejecute antes de que se aplique la confirmación. Con tus scripts existentes para ejecutar el linting y el formateo, esto se llama precommit, donde, con herramientas como Husky, puedes integrar 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 de Git, de modo que cuando ejecutamos nuestro hook previo a la confirmación, no estamos afectando a todo el árbol del repositorio, solo estamos impactando los archivos que realmente cambiaron. Pero una vez que ese script termina, esos cambios se agregan a la etapa de Git antes de que se aplique la confirmación. Entonces, cuando ocurre la confirmación real, Git solo sabe que el código está bonito y formateado. Todo lo que el desarrollador sabe es que hizo su trabajo y cuando el código se implementa en 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 previo a la confirmación, por ejemplo, ya que eso sería muy molesto para los desarrolladores. Imagina que estás trabajando en un proyecto con un conjunto de pruebas enorme y para confirmar, debes ejecutar todo el conjunto de pruebas.

3. Automatización de Procesos CI-CD con Frameworks

Short description:

Los procesos CI-CD automatizan la implementación e integración de código. Los frameworks populares como Jenkins, Bamboo, CircleCI y Travis CI ofrecen diferentes niveles de scripting y configuración. Configurar CI-CD permite una orquestación poderosa de la infraestructura, desde implementar lambdas hasta crear reglas de red. Sin embargo, algunos frameworks, como Jenkins, pueden ser difíciles de trabajar, especialmente para los ingenieros de front-end. A menudo requieren mantenimiento del servidor y tiempos de compilación largos. Una solución más deseable es una opción plug-and-play.

No. No. No. No. Así que 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.

Si bien algunos equipos aún requieren que se inicie manualmente, eso va en contra del propósito, donde el objetivo de CI-CD es automatizar los procesos de código. Por ejemplo, si deseas enviar tus cambios a la rama principal, eso activa un conjunto específico de funcionalidades. Y si envías a una rama de características, tal vez eso active 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 verse 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. Personalmente, todavía tengo pesadillas de trabajar con Jenkins, donde soy principalmente un ingeniero de front-end. Pero el equipo de DevOps juraba por él. Creo que principalmente debido a la flexibilidad, aunque no necesariamente a la facilidad de uso.

Pero configurar CI-CD puede ser muy poderoso. Puedes tener una orquestación grande y compleja de toda tu infraestructura. ¿Necesitas implementar algunas lambdas o almacenar un sitio estático? Agrega un script a tus procesos CI-CD. ¿Necesitas crear una VPC con reglas estrictas de red? Bueno, tal vez Jenkins pueda hacer eso por ti. Porque realmente estás aprovechando el scripting y la automatización de ese scripting, deberías poder lograr cualquier cosa que desees. Pero como mencioné antes, soy un ingeniero de front-end y tuve problemas con Jenkins. No tenía una documentación excelente a la que recurrir. Al menos en ese momento. Y esperar a que las compilaciones 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 node, pero realmente no quiero lidiar con servidores. Los servidores son tan de la década pasada, ¿verdad? Bromas aparte, quiero algo que pueda usar fácilmente sin complicaciones.

4. GitHub Actions y Acciones Personalizadas

Short description:

Las GitHub Actions son flexibles y accesibles. Te permiten configurar el entorno, ejecutar pruebas, implementar código y automatizar tareas. Incluso puedes crear acciones personalizadas para tener más control. Con solo unas pocas líneas, puedes hacer muchas cosas increíbles.

Algo que esté cerca del resto de mi código y con lo que no tenga que luchar. Y después de toda esa preparación, es donde entran en juego 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 también son flexibles. Con Actions, puedes comenzar configurando el entorno en el que deseas ejecutar el archivo de flujo de trabajo. Puedes agregar los comandos que desees, cuando quieras ejecutarlos, y listo.

Por ejemplo, si quiero ejecutar algunas pruebas, puedo configurar un archivo de prueba para ejecutarse en Ubuntu, u otras opciones. Luego puedo verificar ese código donde se ejecutarán los comandos dentro de un directorio de trabajo. Para configurar Node, puedo agregar otra Acción donde especifique la versión. Incluso puedo hacer que se ejecute en diferentes versiones de Node si quiero, dentro del mismo flujo de trabajo. Y finalmente, instalo las dependencias y ejecuto las pruebas. Esto asegurará que las pruebas se ejecuten cada vez que se realice un cambio o se cree una solicitud de extracción en esta instancia en particular.

A medida que se ejecutan, aparecen junto con el resto de la solicitud de extracción, lo que te permite saber con solo un vistazo rápido si tus cambios propuestos realmente rompen algo o no. Esto ayuda a obtener un gran ciclo de retroalimentación para los desarrolladores, cuando algo no funciona, recibirán rápidamente esa retroalimentación. También puedo usar las GitHub Actions para implementar código. Una vez que instalo las dependencias del proyecto, puedo construir ese proyecto. Luego configuro mis credenciales de AWS como secretos y puedo sincronizar esos artefactos con AWS para implementar. La CLI de AWS está disponible de forma predeterminada, lo que hace que esto sea realmente sencillo de hacer dentro de las acciones. Y esto incluye cualquier tipo de comando con la CLI de AWS. Incluso puedo usar acciones del mercado de GitHub.

Si quiero enviar un mensaje a Slack cuando se crea una nueva solicitud de extracción, puedo usar la acción de enviar a 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 ejemplos fueron bastante simples, pero demuestran que con solo unas pocas líneas, realmente podemos hacer muchas cosas increíbles. Lo interesante, sin embargo, es que podemos llevar esto a otro nivel. Podemos crear nuestras propias acciones personalizadas de GitHub. Una vez que creas una acción personalizada de GitHub, realmente obtienes la flexibilidad para hacer lo que quieras dentro de ese entorno controlado. Tienes algunas opciones diferentes, como ejecutar JavaScript con Node, o incluso ejecutarlo con Docker, donde tienes la capacidad de hacer lo que quieras. Por ejemplo, si tengo una tarea común que incluye muchas cosas complicadas, es posible que no quiera 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 esta manera, solo tengo que hacer esa única referencia dentro del flujo de trabajo de la acción entre todos mis diferentes proyectos.

5. Acción de AppleTools Eyes para GitHub

Short description:

Creé una acción de AppleTools Eyes para GitHub que simplifica las pruebas visuales. Con solo un fragmento de código y tu clave de API, puedes ejecutar fácilmente pruebas en tu sitio web o aplicación.

Eso es exactamente lo que hice con mi acción de AppleTools Eyes para GitHub. 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 aplicación móvil y compara esas imágenes con IA. Para hacer eso, Appletools tiene una gran cantidad de SDK, ya sea Cypress, como ves aquí, o Selenium Java, o cualquier otro marco de pruebas popular que te permita agregar el SDK a 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 no tenga configuradas las pruebas en su proyecto pueda agregar esto fácilmente y obtener pruebas visuales, y ahí es donde entra en juego la acción de AppleTools Eyes para GitHub. Y por lo tanto, esta acción solo requiere un fragmento de código donde debes ingresar tu clave de API, que es necesaria cada vez que deseas ejecutar una prueba en Appletools para asegurarte de que realmente se envíe a tu cuenta. Y de esa manera, proporcionas la URL de lo que realmente deseas probar.

6. Automatización de pruebas visuales con AppleTools.eyes

Short description:

El proceso comienza rastreando la URL proporcionada, ya sea haciendo clic en el sitio o utilizando un sitemap personalizado. Se utiliza el paquete Sitemap Generator para rastrear y recopilar los detalles del sitio. Luego, se ejecuta Cypress dentro de un script de nodo, lo que permite recopilar resultados y brindar una mejor experiencia para el desarrollador. Las pruebas se ejecutan dinámicamente en función de las URL y los resultados se pueden comentar en la solicitud de extracción. La acción AppleTools.eyes se puede integrar en un flujo de trabajo existente de Netlify, simplificando el proceso de pruebas visuales para múltiples proyectos.

Una vez que esa acción comienza, inicia un proceso en el que primero rastreamos esa URL que pasas. Esto se hace de manera similar a lo que esperarías de Google cuando utiliza robots para buscar con SEO, donde hace clic en el sitio, rastrea los enlaces disponibles en tu sitio y los agrupa en una lista. O si ya tienes un sitemap personalizado, puedes pasar eso como la URL en su lugar.

Pero para rastrear, utilizo un paquete llamado Sitemap Generator, donde puedo ejecutar un simple comando de nodo y tener todo eso en 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 sitemap como un array que paso directamente a Cypress, lo que me permite recopilar todos mis resultados que puedo usar más adelante, como fallar la acción si las pruebas realmente fallan o trabajar en general con los resultados para brindar una mejor experiencia para el desarrollador dentro del repositorio de GitHub.

Pero finalmente, Cypress ejecuta esas pruebas como lo haría normalmente, dándome mi ejecutor de pruebas y mis resultados para la verificación visual. La única diferencia es que esta vez, está recorriendo todas esas páginas para verificar el sitemap, por lo que está ejecutando todas esas pruebas diferentes de manera dinámica en función de las URL. Pero eso me brinda mi ejecutor de pruebas y mis resultados para esa verificación visual. Con esos resultados, puedo comentar directamente en la solicitud de extracción, ya sea que hayan pasado, fallado o estén sin resolver, lo que le brinda al mantenedor del proyecto una forma fácil de saber si el código realmente introdujo un error o, como mínimo, introdujo un cambio que rompe algo. Incluso encontré una solución donde podemos integrar esto en un flujo de trabajo existente de Netlify. Si no estás familiarizado con Netlify, ellos automáticamente implementarán tu aplicación estática directamente desde GitHub. Y esto sucede cada vez que realizas un cambio en la rama predeterminada de tu repositorio de GitHub. Pude encontrar una acción que esperaba esa implementación y 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 trabajo, recorrió el sitio y realizó esa prueba visual. Pero en última instancia, todo el proyecto es un script que necesito ejecutar. Donde ejecutarlo entre algunos proyectos diferentes es solo unos pocos parámetros de entrada diferentes. En lugar de tener que asegurarme de que mi marco de pruebas esté configurado en cada proyecto, junto con la instalación del SDK y la escritura de todas mis pruebas, esto hace que sea realmente fácil agregar pruebas visuales de AppleTools.eyes a cualquier proyecto con solo estas pocas líneas.

7. Acciones de GitHub y Plantilla de Recordatorio de Contenido

Short description:

Vamos a explorar otros ejemplos de acciones de GitHub, como la plantilla de recordatorio de contenido. Esta plantilla ayuda a los creadores de contenido y educadores a recordar compartir contenido antiguo y tutoriales. Se ejecuta como un script de Node en un cronograma, enviando recordatorios por correo electrónico para compartir entradas aleatorias de fuentes RSS.

Así que también vamos a ver algunos otros ejemplos de acciones de GitHub que están disponibles. También creé una plantilla de acción de GitHub llamada recordatorio de contenido. Lo único con lo que tengo dificultades como creador de contenido y educador es simplemente recordar compartir algunos de mis contenidos antiguos y tutoriales. 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 cronograma para que se active dos veces al día. Con Actions, no solo puedes ejecutar en eventos de GitHub, también puedes ejecutar en la misma sintaxis de cron que estás acostumbrado a programar otras ejecuciones. Pero una vez que se ejecuta, ejecuto un script de Node, donde reviso algunas fuentes RSS de mi contenido, encuentro una entrada aleatoria y me envío un correo electrónico con ese contenido para animarme a compartirlo con el mundo. Para otro caso de uso práctico, el rendimiento es o al menos debería ser una prioridad para todos al construir aplicaciones web. Lighthouse es una herramienta fantástica del equipo de Google que ayuda a medir ese rendimiento. La acción de Lighthouse CI nos permite incluir todas esas 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 de Lighthouse CI. También podemos definir un presupuesto de rendimiento, como el tamaño máximo de la página, pero cuando Lighthouse realmente se ejecuta, tendrá en cuenta ese presupuesto y, si encuentra algún problema, agregará anotaciones directamente en GitHub, informándonos cuáles son esos problemas exactos. Para llevar las cosas al mundo real, Alfonzo creó el issue Tron 3000 para un hackathon de GitHub. Cada vez que se crea un nuevo issue, enviará una señal a un dispositivo IoT, y aunque no estoy muy familiarizado con todo el mundo del IoT, la configuración es similar a cualquier otra acción, donde hay una extensa documentación si realmente quieres aprender cómo configurar esto. Pero en última instancia, se ejecutará un script que Alfonzo configuró dentro de esa acción, donde se configura el cliente MQTT y se envía una carga útil según el evento. Y una vez recibido, el issue Tron 3000 se activa y parpadea o se ilumina según esa configuración. Funciona bastante bien en el video. Lo incluiré en el enlace de mis notas de la charla. Y finalmente, si el último no se consideró divertido, aquí tienes un poco de diversión. Donde Tim creó un juego de ajedrez de comunidad en su página de perfil de GitHub, todo impulsado por las acciones de GitHub. Para hacer un nuevo movimiento, cualquiera puede hacer clic en uno de los enlaces a un espacio específico, donde todo lo que hace es abrir un nuevo issue con esa ubicación en el título. Una vez que la acción ve la solicitud abierta, en última instancia, ejecuta un script de Ruby para configurar ese juego. Incluyendo el análisis real del título del issue donde puedes ver dónde debería ser el siguiente movimiento. Junto con muchas otras cosas dentro de ese script que no se muestran aquí. Además, también está actualizando ese README con el nuevo movimiento. Después de que se acepta el movimiento, aparecerá en el perfil de Tim. Y si eres lo suficientemente persistente con todos tus movimientos, es posible que incluso aparezcas en la tabla de clasificación. Pero lo que sea que hagas con las acciones, el objetivo es automatizar en última instancia la mayor cantidad posible de tu código o todas tus tareas de código que puedas. Nuevamente, deja que los robots hagan el trabajo duro y sean los malos. 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 cualquier persona que quiera usarlas. Ya no me estreso cuando trabajo con flujos de trabajo de CI CD. Me encanta configurar una nueva acción y descubrir qué puedo automatizar. Me emociona tener algo que se ejecute automáticamente y que ya no tenga que hacer yo mismo, y estoy seguro de que a ti también te pasará lo mismo. Si quieres aprender cómo crear tu propia acción de GitHub o si quieres una introducción rápida sobre cómo empezar con las acciones, tengo un montón de recursos disponibles, incluyendo un curso en Egghead y muchos videos en YouTube. Y si quieres aprender cómo ir desde el diseño hasta una aplicación de Next.js de pila completa, incluyendo la automatización de todas tus tareas de código con las acciones de GitHub, echa un vistazo a mi curso gratuito en YouTube, que también puedes encontrar 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 tuitearé un enlace con las cosas que has visto aquí hoy. Gracias a todos.

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

DevOps.js Conf 2022DevOps.js Conf 2022
33 min
Fine-tuning DevOps for People over Perfection
Demand for DevOps has increased in recent years as more organizations adopt cloud native technologies. Complexity has also increased and a "zero to hero" mentality leaves many people chasing perfection and FOMO. This session focusses instead on why maybe we shouldn't adopt a technology practice and how sometimes teams can achieve the same results prioritizing people over ops automation & controls. Let's look at amounts of and fine-tuning everything as code, pull requests, DevSecOps, Monitoring and more to prioritize developer well-being over optimization perfection. It can be a valid decision to deploy less and sleep better. And finally we'll examine how manual practice and discipline can be the key to superb products and experiences.
DevOps.js Conf 2022DevOps.js Conf 2022
27 min
Why is CI so Damn Slow?
We've all asked ourselves this while waiting an eternity for our CI job to finish. Slow CI not only wrecks developer productivity breaking our focus, it costs money in cloud computing fees, and wastes enormous amounts of electricity. Let’s take a dive into why this is the case and how we can solve it with better, faster tools.
DevOps.js Conf 2022DevOps.js Conf 2022
31 min
The Zen of Yarn
In the past years Yarn took a spot as one of the most common tools used to develop JavaScript projects, in no small part thanks to an opinionated set of guiding principles. But what are they? How do they apply to Yarn in practice? And just as important: how do they benefit you and your projects?
In this talk we won't dive into benchmarks or feature sets: instead, you'll learn how we approach Yarn’s development, how we explore new paths, how we keep our codebase healthy, and generally why we think Yarn will remain firmly set in our ecosystem for the years to come.
DevOps.js Conf 2024DevOps.js Conf 2024
25 min
Atomic Deployment for JS Hipsters
Deploying an app is all but an easy process. You will encounter a lot of glitches and pain points to solve to have it working properly. The worst is: that now that you can deploy your app in production, how can't you also deploy all branches in the project to get access to live previews? And be able to do a fast-revert on-demand?Fortunately, the classic DevOps toolkit has all you need to achieve it without compromising your mental health. By expertly mixing Git, Unix tools, and API calls, and orchestrating all of them with JavaScript, you'll master the secret of safe atomic deployments.No more need to rely on commercial services: become the perfect tool master and netlifize your app right at home!
DevOps.js Conf 2021DevOps.js Conf 2021
33 min
How to Build CI/CD Pipelines for a Microservices Application
Top Content
Microservices present many advantages for running modern software, but they also bring new challenges for both Deployment and Operational tasks. This session will discuss advantages and challenges of microservices and review the best practices of developing a microservice-based architecture.We will discuss how container orchestration using Kubernetes or Red Hat OpenShift can help us and bring it all together with an example of Continuous Integration and Continuous Delivery (CI/CD) pipelines on top of OpenShift.

Workshops on related topic

DevOps.js Conf 2022DevOps.js Conf 2022
152 min
MERN Stack Application Deployment in Kubernetes
Workshop
Deploying and managing JavaScript applications in Kubernetes can get tricky. Especially when a database also has to be part of the deployment. MongoDB Atlas has made developers' lives much easier, however, how do you take a SaaS product and integrate it with your existing Kubernetes cluster? This is where the MongoDB Atlas Operator comes into play. In this workshop, the attendees will learn about how to create a MERN (MongoDB, Express, React, Node.js) application locally, and how to deploy everything into a Kubernetes cluster with the Atlas Operator.
React Summit 2023React Summit 2023
88 min
Deploying React Native Apps in the Cloud
WorkshopFree
Deploying React Native apps manually on a local machine can be complex. The differences between Android and iOS require developers to use specific tools and processes for each platform, including hardware requirements for iOS. Manual deployments also make it difficult to manage signing credentials, environment configurations, track releases, and to collaborate as a team.
Appflow is the cloud mobile DevOps platform built by Ionic. Using a service like Appflow to build React Native apps not only provides access to powerful computing resources, it can simplify the deployment process by providing a centralized environment for managing and distributing your app to multiple platforms. This can save time and resources, enable collaboration, as well as improve the overall reliability and scalability of an app.
In this workshop, you’ll deploy a React Native application for delivery to Android and iOS test devices using Appflow. You’ll also learn the steps for publishing to Google Play and Apple App Stores. No previous experience with deploying native applications is required, and you’ll come away with a deeper understanding of the mobile deployment process and best practices for how to use a cloud mobile DevOps platform to ship quickly at scale.
DevOps.js Conf 2022DevOps.js Conf 2022
13 min
Azure Static Web Apps (SWA) with Azure DevOps
WorkshopFree
Azure Static Web Apps were launched earlier in 2021, and out of the box, they could integrate your existing repository and deploy your Static Web App from Azure DevOps. This workshop demonstrates how to publish an Azure Static Web App with Azure DevOps.
DevOps.js Conf 2022DevOps.js Conf 2022
163 min
How to develop, build, and deploy Node.js microservices with Pulumi and Azure DevOps
Workshop
The workshop gives a practical perspective of key principles needed to develop, build, and maintain a set of microservices in the Node.js stack. It covers specifics of creating isolated TypeScript services using the monorepo approach with lerna and yarn workspaces. The workshop includes an overview and a live exercise to create cloud environment with Pulumi framework and Azure services. The sessions fits the best developers who want to learn and practice build and deploy techniques using Azure stack and Pulumi for Node.js.