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!
This talk has been presented at DevOps.js Conf 2024, check out the latest edition of this Tech Conference.
FAQ
Una implementación atómica implica desplegar solo los cambios entre dos versiones de una aplicación, de manera que cada versión es autocontenida y se puede revertir fácilmente sin afectar otras partes del sistema.
Netlify utiliza implementaciones atómicas al permitir que los cambios se desplieguen automáticamente a través de un push a una rama en un servidor de versiones como GitHub, facilitando la gestión y visualización de versiones previas y nuevas.
Matt busca que las implementaciones sean configurables, compatibles a largo plazo con cualquier proveedor de alojamiento y que incluyan un micro-CI para la gestión de dependencias y construcción, todo manejado automáticamente por la solución.
Matt utiliza comandos de Git y Bash para automatizar el proceso de implementación, y se apoya en ganchos de Git como post-receive para manejar actualizaciones y despliegues automáticos en el servidor.
Matt emplea una estrategia de enlaces duros para copiar solo los archivos que han cambiado desde la última versión, lo que minimiza el tiempo de inactividad y mantiene cada versión autocontenida y optimizada.
Matt configura las implementaciones para que sean agnósticas a cualquier proveedor de alojamiento y utiliza configuraciones locales de Git para ajustar el entorno del proyecto, garantizando flexibilidad y adaptabilidad a largo plazo.
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.
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
NPM workspaces help manage multiple nested packages within a single top-level package, improving since the release of NPM CLI 7.0. You can easily add dependencies to workspaces and handle duplications. Running scripts and orchestration in a monorepo is made easier with NPM workspaces. The npm pkg command is useful for setting and retrieving keys and values from package.json files. NPM workspaces offer benefits compared to Lerna and future plans include better workspace linking and adding missing features.
Remix Flat Routes is a new convention that aims to make it easier to see and organize the routes in your app. It allows for the co-location of support files with routes, decreases refactor and redesign friction, and helps apps migrate to Remix. Flat Folders convention supports co-location and allows importing assets as relative imports. To migrate existing apps to Flat Routes, use the Remix Flat Routes package's migration tool.
We will learn how to automate code and testing with GitHub Actions, including linting, formatting, testing, and deployments. Automating deployments with scripts and Git hooks can help avoid mistakes. Popular CI-CD frameworks like Jenkins offer powerful orchestration but can be challenging to work with. GitHub Actions are flexible and approachable, allowing for environment setup, testing, deployment, and custom actions. A custom AppleTools Eyes GitHub action simplifies visual testing. Other examples include automating content reminders for sharing old content and tutorials.
DevOps is a journey that varies for each company, and remote work makes transformation challenging. Pull requests can be frustrating and slow, but success stories like Mateo Colia's company show the benefits of deploying every day. Challenges with tools and vulnerabilities require careful consideration and prioritization. Investing in documentation and people is important for efficient workflows and team growth. Trust is more important than excessive control when deploying to production.
Slow CI has a negative impact on productivity and finances. Debugging CI workflows and tool slowness is even worse. Dependencies impact CI and waiting for NPM or YARN is frustrating. The ideal CI job involves native programs for static jobs and lightweight environments for dynamic jobs. Improving formatter performance and linting is a priority. Performance optimization and fast tools are essential for CI and developers using slower hardware.
Today's Talk discusses rethinking CI in monorepos, with a focus on leveraging the implicit graph of project dependencies to optimize build times and manage complexity. The use of NX Replay and NX Agents is highlighted as a way to enhance CI efficiency by caching previous computations and distributing tasks across multiple machines. Fine-grained distribution and flakiness detection are discussed as methods to improve distribution efficiency and ensure a clean setup. Enabling distribution with NX Agents simplifies the setup process, and NX Cloud offers dynamic scaling and cost reduction. Overall, the Talk explores strategies to improve the scalability and efficiency of CI pipelines in monorepos.
Sumérgete en el mundo de la IA con nuestro masterclass interactivo diseñado específicamente para desarrolladores web. "Masterclass: Integrando LangChain con JavaScript para Desarrolladores Web" ofrece una oportunidad única para cerrar la brecha entre la IA y el desarrollo web. A pesar de la prominencia de Python en el desarrollo de IA, el vasto potencial de JavaScript sigue siendo en gran medida inexplorado. Este masterclass tiene como objetivo cambiar eso.A lo largo de esta sesión práctica, los participantes aprenderán cómo aprovechar LangChain, una herramienta diseñada para hacer que los modelos de lenguaje grandes sean más accesibles y útiles, para construir agentes de IA dinámicos directamente dentro de entornos JavaScript. Este enfoque abre nuevas posibilidades para mejorar las aplicaciones web con funciones inteligentes, desde el soporte al cliente automatizado hasta la generación de contenido y más.Comenzaremos con los conceptos básicos de LangChain y los modelos de IA, asegurando una base sólida incluso para aquellos nuevos en IA. A partir de ahí, nos sumergiremos en ejercicios prácticos que demuestran cómo integrar estas tecnologías en proyectos reales de JavaScript. Los participantes trabajarán en ejemplos, enfrentando y superando los desafíos de hacer que la IA funcione sin problemas en la web.Este masterclass es más que una experiencia de aprendizaje; es una oportunidad de estar a la vanguardia de un campo emergente. Al final, los asistentes no solo habrán adquirido habilidades valiosas, sino que también habrán creado funciones mejoradas con IA que podrán llevar a sus proyectos o lugares de trabajo.Ya seas un desarrollador web experimentado curioso acerca de la IA o estés buscando expandir tus habilidades en áreas nuevas y emocionantes, "Masterclass: Integrando LangChain con JavaScript para Desarrolladores Web" es tu puerta de entrada al futuro del desarrollo web. Únete a nosotros para desbloquear el potencial de la IA en tus proyectos web, haciéndolos más inteligentes, interactivos y atractivos para los usuarios.
Desplegar aplicaciones React Native manualmente en una máquina local puede ser complejo. Las diferencias entre Android e iOS requieren que los desarrolladores utilicen herramientas y procesos específicos para cada plataforma, incluidos los requisitos de hardware para iOS. Los despliegues manuales también dificultan la gestión de las credenciales de firma, las configuraciones de entorno, el seguimiento de las versiones y la colaboración en equipo. Appflow es la plataforma de DevOps móvil en la nube creada por Ionic. Utilizar un servicio como Appflow para construir aplicaciones React Native no solo proporciona acceso a potentes recursos informáticos, sino que también simplifica el proceso de despliegue al proporcionar un entorno centralizado para gestionar y distribuir tu aplicación en múltiples plataformas. Esto puede ahorrar tiempo y recursos, permitir la colaboración, así como mejorar la confiabilidad y escalabilidad general de una aplicación. En este masterclass, desplegarás una aplicación React Native para su entrega en dispositivos de prueba Android e iOS utilizando Appflow. También aprenderás los pasos para publicar en Google Play y Apple App Stores. No se requiere experiencia previa en el despliegue de aplicaciones nativas, y obtendrás una comprensión más profunda del proceso de despliegue móvil y las mejores prácticas para utilizar una plataforma de DevOps móvil en la nube para enviar rápidamente a gran escala.
Walt te mostrará 2 formas de crear rápidamente un sitio web en Vultr: desde cero utilizando archivos HTML y CSS con Object Storage, y con el Marketplace de 1 clic de Vultr.
Desplegar y gestionar aplicaciones JavaScript en Kubernetes puede volverse complicado. Especialmente cuando una base de datos también debe formar parte del despliegue. MongoDB Atlas ha facilitado mucho la vida de los desarrolladores, sin embargo, ¿cómo se integra un producto SaaS con su clúster de Kubernetes existente? Aquí es donde entra en juego el Operador de MongoDB Atlas. En este masterclass, los asistentes aprenderán cómo crear una aplicación MERN (MongoDB, Express, React, Node.js) localmente y cómo desplegar todo en un clúster de Kubernetes con el Operador de Atlas.
¿Incluyen tus pruebas automatizadas verificaciones de accesibilidad? Este masterclass cubrirá cómo comenzar con jest-axe para detectar violaciones de accesibilidad basadas en código, y Lighthouse CI para validar la accesibilidad de las páginas completamente renderizadas. Ninguna cantidad de pruebas automatizadas puede reemplazar las pruebas manuales de accesibilidad, pero estas verificaciones se asegurarán de que tus probadores manuales no estén haciendo más trabajo del necesario.
Las Azure Static Web Apps se lanzaron a principios de 2021 y, de forma predeterminada, pueden integrar su repositorio existente y implementar su aplicación web estática desde Azure DevOps. Este masterclass demuestra cómo publicar una Azure Static Web App con Azure DevOps.
Comments