Despliegue Atómico para Hipsters de JavaScript

Rate this content
Bookmark

Desplegar una aplicación no es un proceso fácil. Te encontrarás con muchos problemas y puntos de dolor que resolver para que funcione correctamente. Lo peor es: ahora que puedes desplegar tu aplicación en producción, ¿cómo no vas a poder desplegar también todas las ramas del proyecto para tener acceso a vistas previas en vivo? ¿Y poder hacer un revert rápido a pedido?

Afortunadamente, el clásico conjunto de herramientas de DevOps tiene todo lo que necesitas para lograrlo sin comprometer tu salud mental. Al mezclar expertamente Git, herramientas de Unix y llamadas a API, y orquestar todo ello con JavaScript, dominarás el secreto de los despliegues atómicos seguros.

No necesitarás depender de servicios comerciales: ¡conviértete en el maestro perfecto de las herramientas y netlifica tu aplicación desde casa!

25 min
15 Feb, 2024

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Esta charla discute el despliegue atómico para JavaScript y TypeScript, centrándose en los procesos de despliegue automatizados, los ganchos de Git y el uso de enlaces duros para copiar los cambios. El orador demuestra cómo configurar un repositorio vacío, configurar variables de despliegue y utilizar el gancho post-receive para enviar los cambios a producción. También se cubre la configuración del entorno, la configuración de las ramas y el proceso de compilación. La charla concluye con consejos sobre casos de uso reales, webhooks y la envoltura del proceso de despliegue.

Available in English

1. Introducción a la implementación atómica

Short description:

Vamos a hablar sobre la implementación atómica para Hipsters de JavaScript y TypeScript. En una implementación atómica, tomas dos versiones de una aplicación existente y despliegas los cambios entre ellas. Es autocontenido y elimina la necesidad de preocuparse por las dependencias y la construcción. El objetivo es tener una solución funcional, trabajable y compatible con una experiencia de desarrollo sencilla.

Hola, amigos. Bienvenidos a esta charla para nosotros, la Conferencia de DevOps JS. Vamos a hablar sobre la implementación atómica para Hipsters de JavaScript y TypeScript. Justo antes de comenzar, un poco de información sobre qué es la implementación atómica y la implementación inmutable. En una implementación atómica, tomas dos versiones de una aplicación existente y solo despliegas los cambios entre esas dos versiones, pero todo está autocontenido. Por lo tanto, puedes tomar un archivo completo de una versión en cualquier momento y todo está autocontenido y no tienes que preocuparte por nada al respecto. Esto es lo que hizo que Netlify fuera tan exitoso en el pasado porque de repente solo tenías que hacer push a una rama en tu servidor de versiones como GitHub o cualquier otro, y se desplegaba automáticamente en tu servidor de producción en una URL de preparación como mybranch slash myapp.mydomain.com. Es realmente poderoso porque solo tienes que hacer push de algunos cambios en cualquier tipo de rama y automáticamente tienes muchas vistas previas accesibles directamente. Y cada vez que actualizas tu rama, como actualizar tu PR, la vista previa se actualiza de la misma manera. Así que definitivamente es útil, especialmente cuando el despliegue es un proceso doloroso cuando tienes que preocuparte por las dependencias y la construcción, y así sucesivamente. Entonces, ¿cuál es la forma hipster de hacer este tipo de implementaciones atómicas o inmutables? Mi idea es mantener que funcione. Quiero adherirme a los principios de las implementaciones atómicas e inmutables. Quiero que sea funcional, trabajable y compatible con cualquier proveedor de alojamiento, cualquiera que sea. Y quiero mantener la experiencia de desarrollo sencilla. Como, solo quiero hacer push a mi rama y mi vista previa se despliega o actualiza automáticamente, y eso es todo. Y no me importa cómo usarlo y cómo trabajar con él, y así sucesivamente. Entonces, ¿cuáles son las características esperadas en estas implementaciones específicamente? Quiero que sea configurable porque no quiero rehacer todo el proceso para cada proyecto. Quiero tener algo que se pueda desplegar fácilmente en cualquier tipo de repositorio y donde solo tenga que ajustar algunas variables para configurarlo para este proyecto específico en un momento dado. Quiero que sea compatible a largo plazo, que funcione en cualquier tipo de proveedor de alojamiento en el mundo real. Quiero algún tipo de micro-CI integrado como dependencias de despliegue y construcción, y así sucesivamente. Todo manejado por la solución en sí misma. Por lo tanto, no tengo que preocuparme por nada al respecto. Pero sin las pruebas y demás, no importa. Quiero que el tiempo de inactividad en el despliegue sea mínimo para mantenerlo realmente funcionando. Por lo tanto, no quiero romper algo en producción solo porque hice push a una rama que de repente no se construyó o algo más. Entonces, quiero algún tipo de salvaguardias en algunos puntos para asegurarme de que nada pueda fallar en algún momento. Y quiero que sea auto-publicable. Así que solo quiero hacer push en una rama y boom, mis ramas, mi vista previa asociada a mi rama se actualiza automáticamente. Soy Matt, amigos. Soy un ingeniero de experiencia de desarrollo en Always Data, que es un proveedor de alojamiento, uno independiente.

2. Configuración de la implementación automatizada

Short description:

Te mostraré los fundamentos de nuestro proceso de implementación automatizada con características de implementación atómica e inmutable. Trabajaremos en el servidor, tendremos los hosts web y los repositorios en el mismo lugar y nos basaremos en el acceso remoto SSH. Inicializaré un repositorio vacío y lo vincularé a una nueva aplicación.

Entonces, mi responsabilidad en Always Data es trabajar en la experiencia del desarrollador, más específicamente en la CLI y las herramientas asociadas a la plataforma misma. Lo que te mostraré es definitivamente la base de nuestro proceso de implementación automatizada con características de implementación atómica e inmutable. Actualmente está en proceso de desarrollo en la CLI, pero estará disponible pronto. Estoy muy feliz de compartirlo contigo porque es definitivamente el resultado de mi búsqueda. Así que sumerjámonos en el código para ver cómo funciona. Nuestras premisas para esta charla específica son que trabajaremos en el servidor y todo en un servidor, lo que significa que, sea lo que sea, un contenedor, VPS, metal desnudo, lo que quieras para compartir el contenido en un proveedor de alojamiento, no me importa. Pero la idea es que quiero tener en el mismo lugar los hosts web y los repositorios que son responsables de la implementación atómica, la versión, etc. No es obligatorio para esta solución, pero definitivamente es más simple de explicar. Me basaré en una cuenta de sistema única de alojamiento web como `www` para cualquier distribución basada en Debian, pero digamos que todo será manejado por el mismo usuario del sistema en algún momento, repositorio y hosts web. Nos basaremos mucho en el acceso remoto SSH. Por lo tanto, necesitas un acceso remoto SSH a tu solución. Y no utilizaré webhooks para esto, no es que no me gusten, pero está totalmente fuera del alcance de esta charla. Así que hablaré un poco de ellos en la conclusión. Obviamente, cuando vuelva a hablar de ellos, habremos alcanzado

3. Configuración de la implementación

Short description:

La idea es que te bases en los conceptos básicos de Git. Accederé directamente al servidor en mi contenedor y crearé un repositorio vacío en la misma carpeta. Luego crearé una nueva aplicación y la vincularé al repositorio. Configuraré el proyecto utilizando git config para variables específicas, como la carpeta dist para la implementación.

la conclusión. Así que vamos a iniciar. La idea es que te bases en los conceptos básicos de Git. Así que accederé directamente al servidor en mi contenedor con mi cuenta de alojamiento, y me aseguraré de estar en la carpeta /var, porque en /var hay una carpeta llamada www. Esta es la ruta de documentos para nuestro motor de servidor web, como Apigee o Nginx o Traphic o cualquier otro que desees, no me importa. Inicializaré un repositorio, un repositorio vacío en la misma carpeta en /var/repo. Un repositorio vacío es más o menos lo mismo que tienes en la carpeta .git en tu árbol de trabajo, pero solo tienes los diferentes archivos y elementos dedicados a Git y no el contenido general de tus árboles de origen, porque no me importa dar acceso al código en el servidor en cualquier momento. Así que si verifico, todavía tengo en mi carpeta /var dos subcarpetas, el repositorio en formato vacío y el www1 listo para manejar nuestras aplicaciones web. Así que volvamos localmente a mi computadora. Me moveré a la carpeta de mi proyecto, donde quieras almacenar tu proyecto. Tú decides. Crearé una nueva aplicación, por ejemplo, utilizando Vite con plantillas, así que crearé una aplicación en mi carpeta app. Así que está en mi carpeta app, y ahora puedo ingresar directamente a mi aplicación. Luego vincularé el repositorio previamente creado en mi contenedor a este proyecto localmente. Inicializaré el repositorio con git init, agregaré todo lo que esté disponible en él y haré el primer commit inicial. Así que todo está en el commit raíz en el primer commit en el commit inicial, el primero, inicializándolo. Agregaré un remoto llamado deploy, que apunta a través de SSH al contenedor y a la carpeta /var/repo que creamos antes. ¿Por qué deploy y no origin? Porque probablemente queramos mantener origin para nuestro servidor de versiones, como GitHub o GitLab o cualquier otro que desees. Y puedes tener tantos remotos como desees en Git, así que ¿por qué no llamar a este deploy, porque está listo para manejar el proceso de implementación y mantener origin para el original, el regular. Así que puedo hacer git push deploy main. Así que hago push en deploy de la rama main, y obtengo un mensaje de confirmación de Git diciendo, ok, en contenedores, en el repositorio /var, he creado una nueva rama main que apunta a la rama main. ¡Éxito! Ok, ahora vamos a configurarlo. Queremos que el proyecto sea configurable, así que volvamos a través de SSH al repositorio /var. Todavía estamos en nuestro repositorio vacío, y si verifico las configuraciones locales de Git, puedo ver que tengo muy pocas claves de configuración, lo cual es interesante, porque no quiero depender del nuevo archivo de configuración YAML en mi árbol de origen. Quiero tener algunas variables configurables que quiero ajustar solo para este repositorio específico dedicado a la implementación. Así que ¿por qué no confiar en la herramienta git config para hacerlo? El formato siempre es el mismo, rearm.keyed.value. Así que podemos crear una configuración local de git porque queremos mantenerla local. Deals.build.dist, porque en este proyecto, es un proyecto de Vite, por lo que Vite creará una carpeta dist, y es esta carpeta dist la que quiero implementar en mis aplicaciones web y demás. No quiero implementar todo el árbol de origen, solo la carpeta dist. Así que especifico eso para este proyecto específico y lo hago con git config. Hay una construcción dist, y puedo usarla. Así que recomiendo usar dist o lo que sea. No uses nada en lo que Git ya confíe, como core, porque existe el riesgo de sobrescribirlo.

4. Git Hooks y Post Receive Hook

Short description:

Los ganchos de Git te permiten reaccionar a eventos en el ciclo de vida de tu repositorio. El gancho post-receive es particularmente interesante para hacer push a producción. Reacciona a los eventos de git push, se ejecuta en el repositorio remoto y maneja las ramas una por una. Podemos escribirlo en Bash, automatizando comandos de terminal.

Los claves existentes, pero definitivamente puedes confiar en almacenar tu propia configuración. Está abierto, está bien. Así que si verificamos, está bien. Ya está almacenado. Así que vamos a engancharlo. Así que todo lo que ocurra ahora ocurrirá en la carpeta ssh.var.repo. Así que unas palabras sobre los ganchos de Git. Los ganchos de Git son un mecanismo que te permite reaccionar a algunos eventos que ocurren en el ciclo de vida de tu repositorio de Git. En la lista completa, que es muy larga, de diferentes eventos disponibles, hay algunos que son interesantes, y uno en particular es realmente interesante. Es un gancho post-receive, que a menudo se dedica a hacer push al servidor de producción. Interesante. Esto es exactamente lo que estamos tratando de hacer. Así que confiemos en el gancho post-receive. Echemos un vistazo rápido a él.

Es un gancho que reacciona a los eventos de git push. Cuando se realizan actualizaciones, ramas que llegan, se ejecuta en el repositorio remoto. Excelente. Y una vez que todas las referencias se han actualizado, lo cual es interesante, puedo hacer push de todas las ramas, mi repositorio las manejará y reaccionará a todas las ramas una por una. Así que definitivamente puedo actualizar e implementar cada rama una por una cada vez que reciba un evento de git push si contiene diferentes ramas. Pero si solo hay una, está bien. Así que lee las líneas de la entrada estándar, y es un proceso automatizado. Así que lo escribiré en Bash. Puedes confiar en Python o Deno o lo que quieras hacer. Pero solo automatiza un montón de comandos de terminal diferentes. Así que Bash es una gran herramienta para hacerlo. Así que verificamos que todavía estamos en el repositorio. Creamos un archivo post-receive y lo hacemos ejecutable. Así que vamos a inicializarlo. Es un contenido de Bash. Tenemos un bucle while para leer la entrada estándar.

5. Configuración del Entorno y Configuración de Ramas

Short description:

Recuperamos la ruta a la carpeta git pair en el servidor. Si la clave de configuración de implementación no está definida, utilizamos una carpeta en el directorio VVV. Para cada rama, configuramos la rama eliminando el prefijo de 'heads' de la referencia, utilizando un commit de alto costo y creando un directorio temporal. También creamos un directorio de enlace a la referencia de la carpeta de implementación para una mejor legibilidad.

para cada línea. Y en cada línea, tenemos tres tipos de información, una línea, una rama. Y tenemos tres informaciones, el commit de revisión antiguo, el commit de revisión nuevo y la referencia, que obviamente es el nombre de la rama. Así que podemos imprimir en pantalla, trabajando en la rama, blah blah blah.

De acuerdo. Así que tenemos que configurar el entorno. Tenemos que recuperar la ruta a la carpeta git pair en el propio servidor. Podría codificarla directamente, pero quiero que sea agnóstico, así que tengo que detectarlo. Es un poco complicado. No voy a profundizar en ello, pero lo tienes. Tenemos acceso a la carpeta git y entramos en ella como si fuera un CD. Así que entramos en la carpeta git para ejecutar el resto de los comandos. Verificamos si tenemos esta clave de configuración de implementación y si no la hemos definido. Así que podemos utilizar una carpeta en el mismo nivel de la carpeta git en el directorio VVV, que es exactamente lo que tenemos, slash virus slash VVV para la implementación. Así que aquí tenemos una implementación. Verificamos que la carpeta ya esté lista para manejar el resto, y vamos a donde estamos listos para continuar. Así que podemos configurar cada rama, para cada una, podemos configurar la rama. Estamos haciendo algunos trucos para mejorar la legibilidad. Así que tenemos un nombre de referencia, que elimina el prefijo 'heads' de la referencia. Utilizamos solo un commit de alto costo y creamos un directorio temporal para alojar nuestro árbol de código fuente para esta rama específica. También creamos un directorio de enlace a la referencia de la carpeta de implementación, que es una ruta legible, porque no quiero configurar todo mi host web a slash virus slash VVV slash un ID de commit,

6. Working Tree and Build Process

Short description:

Movemos un enlace desde el nombre de referencia hasta el commit actual para la rama. Luego, creamos un árbol de trabajo en la carpeta temporal y lo verificamos. A continuación, manejamos el proceso de compilación verificando la configuración, el diseño del paquete, el bloqueo del paquete y ejecutando el script de compilación. Por último, explicamos el uso de enlaces duros de Unix para copiar solo los archivos modificados para obtener un mejor rendimiento y mantenimiento.

pero quiero que apunten a var VVV, el nombre de mi rama. Así que puedo mover simplemente un enlace, que es solo un puntero desde el nombre de referencia hasta el commit actual dedicado a esta rama. Así que será mejor. Por lo tanto, usamos un enlace para hacerlo y preparamos el nombre del enlace.

De acuerdo, ahora tenemos un árbol de trabajo en la carpeta temporal. Así que verifiquemos el árbol de trabajo. Usamos el comando work tree, que es como un checkout, pero de una manera más potente. Así que agregamos un nuevo árbol de trabajo a esta carpeta temporal basado en esta rama actual. Y nos movemos a él para ingresar a este árbol de trabajo . Tenemos que manejar el proceso de compilación, así que verificamos si tenemos un directorio de compilación configurado. Este es el caso. Lo definimos antes, así que lo tenemos. De lo contrario, es simplemente una carpeta actual. Probamos si tenemos un diseño de paquete disponible. Si es así, probamos si tenemos un bloqueo de paquete. Si es así, hacemos una instalación limpia, porque somos personas limpias, de lo contrario. Hagamos una instalación, pero recuerda hacer tus archivos de registro, y luego podemos ejecutar el script de compilación si el script está presente. Si no, está bien. Está perfectamente bien. Si la compilación falla, el script se cerrará y pasaremos a la siguiente rama. Y todo está protegido de esa manera. Así que vamos a la siguiente. Una breve explicación sobre los enlaces duros de Unix. La idea en el proceso atómico, si recuerdas correctamente, es que solo quiero copiar los archivos que han cambiado desde mi versión anterior a esta. Así que no quiero copiar todo y duplicar el contenido. Mi idea es decir, okay, verifiquemos si tenemos una versión anterior de esta rama. Así que queremos verificar dónde está el punto de bifurcación desde la rama principal o desde la rama de origen, y queremos verificar si hay un commit dedicado a eso. Si es así, si el archivo no ha cambiado entre esta rama de origen y esta nueva, simplemente copiemos este. Simplemente hagamos un enlace duro a esta versión. De lo contrario, copiemos una nueva versión. Será más performance,

7. Despliegue y Enlaces Duros

Short description:

Utilizamos enlaces duros para copiar los cambios y hacer que cada versión sea autocontenida. Para encontrar el punto de bifurcación de la rama actual, necesitamos obtener la lista de revisiones y verificar si cada commit es un ancestro válido. Si lo es, podemos usarlo como base para el despliegue. Si hay un ancestro común, agregamos opciones a air sync para usar la carpeta base y hacer un enlace duro si el archivo no ha cambiado. Desplegamos usando air sync, eliminamos la carpeta de trabajo y creamos enlaces entre los nombres de referencia y revisión.

Será más rápido y definitivamente más fácil de mantener. Y solo copiarás los cambios, pero cada versión será autocontenida. Por eso no confiamos en los enlaces simbólicos, sino que preferimos utilizar enlaces duros para hacerlo. Esto significa que tenemos que encontrar un ancestro de comando git. Supongamos que estamos en la rama fixd. Si estamos allí, podemos suponer que el punto de bifurcación es un commit C1. Pero si le preguntamos a git, hey, ¿cuál es el punto de bifurcación para mi rama actual?, git no escribe nada porque git no almacena realmente un árbol de las diferentes ramas, sino solo una lista de commits. Así que tienes que confiar en ti mismo para hacerlo. Tienes que obtener la lista de revisiones desde la punta de tu rama hasta la rama principal y el commit inicial. Luego tienes que verificar para cada uno de estos commits si es un ancestro válido. Si es el punto de bifurcación de una rama anterior, y si es así, entonces podrías considerar que este commit, si todavía está en una rama, podría ser utilizado como base para el despliegue. ¿Cómo hacerlo en código? Tenemos la lista de revisiones, gracias al comando revlist. Y para cada revisión, es decir, para cada commit en esta lista, retrocedemos en la historia. Y para cada uno de ellos, verificamos si es un posible ancestro para mi rama en esta revisión específica. Si es el caso, es decir, si es el punto de bifurcación, entonces verifiquemos que todavía está en una rama y que esta rama fue desplegada antes. ¿Este commit todavía está disponible? Si es así, entonces podríamos considerar que podemos, como bifurcamos el código, bifurcar el despliegue y usar esta carpeta como carpeta base para la revisión. De lo contrario, simplemente insertamos la revisión y desplegaremos desde cero, y está bien. Es perfectamente legítimo hacerlo. Si tenemos un ancestro común, simplemente agregamos algunas opciones a air sync, que será nuestra herramienta de despliegue, para decir, ok, para esta tarea de copia específica, usa esta carpeta como base. Y si el archivo no cambió entre esta carpeta y la nueva, simplemente haz un enlace duro entre las dos. Así que vamos a desplegar. Confiamos en air sync, como esperabas. Así que desplegaremos desde el directorio de construcción de trabajo dentro de él. Así que mi directorio de disco dentro de mi árbol de trabajo, y lo desplegaremos en mi directorio de despliegue. El commit de ID de revisión. Confiamos en el checksum para hacerlo con la opción de air sync activada. Así que enlaces duros activados, si es confiable en este contexto, y así sucesivamente. Después de eso, simplemente podemos eliminar la carpeta de trabajo del repositorio git porque ya no la necesitamos, y somos personas limpias, así que limpiamos detrás de nosotros. Y luego podemos publicarlo, lo que significa crear los enlaces entre el nombre de referencia y el nombre de revisión. Moviendo el puntero del

8. Publicación y Actualización de la Aplicación

Short description:

Para publicar la aplicación, asegúrate de que todo esté bien, crea el enlace, reinicia el servidor y verifica el nuevo commit. En menos de 60 líneas de código bash, logra el mismo éxito que Netlify.

Para publicar la aplicación, asegúrate de que todo esté bien, creando el enlace. Luego, reiniciamos el servidor. En esta demo, arreglé el reinicio. Simplemente detuve el servidor existente lanzado previamente y cambié aleatoriamente el puerto y lancé un servidor HTTP que apunta a este nuevo enlace de producción que creé antes y que apunta a mi nuevo commit. Y voilà, todo está bien. Esto es para la publicación. Permíteme mostrarte cómo funciona. Regreso a mi carpeta local. Actualizo mi aplicación. Verifico que todavía estoy en mi aplicación. Creo una nueva rama llamada fit/actualizar-nombre. Cambio a esta rama, edito la aplicación, hago un commit con el mensaje de commit elegante 'actualizar nombre' y luego puedo enviarlo. Así que hago git push deploy fit/actualizar-nombre. Envío para desplegar mi rama fit/actualizar-nombre. Y dice que está bien, despliego la rama en VAR vvv. Estamos trabajando en la rama fit/actualizar-nombre. Estoy preparando el árbol de trabajo. Así que nos estamos moviendo al árbol de trabajo en un estado desconectado. Aquí, estamos instalando los paquetes npm. Así que estamos construyendo cosas con npm run build cosas para VIT. Así que estamos produciendo la carpeta dist. Encontramos el commit base de despliegue porque la rama se bifurcó de una rama principal, y estamos desplegando esta carpeta dist en VAR vvv, mi nombre de commit de referencia. Luego podemos hacer el enlace desde fit/actualizar-nombre hasta el ID final del commit. Y reinicio la aplicación. Y si verifico, puedo asegurarte que funciona. Y en menos de 60 líneas de código bash. Para lo mismo.

9. Casos de Uso Reales, Webhooks y Consejos de Envoltura

Short description:

Los casos de uso reales incluyen crear/actualizar sitios web, realizar acciones en la base de datos, invalidar la caché y reiniciar el sitio web. Los webhooks pueden automatizar el proceso de envío y recuperación. Consejos para la envoltura: mantenlo simple, usa la configuración de Git, abstrae los cambios de alojamiento web en llamadas de API y aprovecha Deno o Node.js como sistema de compilación. ¡Gracias por tenerme hoy!

tan exitoso como Netlify. Esto es simplemente increíble. Entonces, ¿cuáles son los casos de uso reales? Porque he dicho que falsifiqué el proceso de reinicio. Probablemente tendrás algún tipo de acciones como crear o actualizar el sitio web con la URL correcta como el nombre de mi rama punto mi aplicación punto mi dominio punto com. Probablemente realizar algunas acciones en la base de datos como migración y así sucesivamente, invalidación de caché, reiniciar el sitio web, lo que desees. Entonces, debes hacerlo, envuélvelos en llamadas de API, reemplazando el contenido falso de reiniciar el servidor HTTP. Pero si son solo archivos estáticos como los que tenemos aquí, simplemente estás creando un nuevo VOS en tu motor web y está bien. Así que eso es genial. ¿Qué hay de los webhooks? Como dije antes, puedes usarlos principalmente para automatizar el envío desde el repositorio de origen al repositorio de implementación. Entonces, cada vez que haces push a GitHub o GitLab o cualquier otro, a tu servidor upstream, gracias a los webhooks, puedes automatizar el proceso de recuperación en la rama del servidor de implementación. Escribí una publicación en el blog al respecto si quieres. Así que puedes usarlos para eso y está perfectamente bien, está perfectamente bien. Solo reduce la fricción en términos de developer experience. Algunos consejos para la envoltura. Mantenlo simple y estúpido. Lo hago realmente agnóstico. No quiero que sea demasiado inteligente ni nada por el estilo. Una vez más, son menos de 60 líneas de código bash. Así que hazlo realmente simple y será mucho más fácil de mantener y adaptar a muchas aplicaciones diferentes. Usa la configuración de Git para almacenar tus variables y procesos de configuración ajustes y demás. Abstrae cualquier cambio en la configuración de tu alojamiento web en llamadas de API utilizando CLI, utilizando la API, utilizando lo que desees. Y definitivamente puedes confiar en Deno o Node.js como sistema de compilación gracias al archivo package json. Puedes crear muchos scripts para ejecutar y asegurarte de que las dependencias estén instaladas, ejecutar el proceso de pre-compilación, el proceso de compilación, el proceso de post-compilación, incluso en aplicaciones complejas escritas en Python, Ruby, Rust, lo que desees. Pero definitivamente puedes usar Node.js como motor de CI para el proceso de compilación. Así que gracias de nuevo. Gracias por tenerme hoy y espero que disfrutes el resto de la conferencia. ¡Adiós!

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

React Advanced Conference 2021React Advanced Conference 2021
19 min
Automating All the Code & Testing Things with GitHub Actions
Top Content
Code tasks like linting and testing are critical pieces of a developer’s workflow that help keep us sane like preventing syntax or style issues and hardening our core business logic. We’ll talk about how we can use GitHub Actions to automate these tasks and help keep our projects running smoothly.
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.

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.
TestJS Summit 2021TestJS Summit 2021
85 min
Automated accessibility testing with jest-axe and Lighthouse CI
Workshop
Do your automated tests include a11y checks? This workshop will cover how to get started with jest-axe to detect code-based accessibility violations, and Lighthouse CI to validate the accessibility of fully rendered pages. No amount of automated tests can replace manual accessibility testing, but these checks will make sure that your manual testers aren't doing more work than they need to.
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.