Construye tu Pipeline de JS de forma incremental con GitLab

Rate this content
Bookmark

Introducir CI/CD en tu proyecto puede ser un proceso desafiante. En GitLab valoramos la iteración como uno de nuestros valores clave, y en espíritu de la iteración estaremos encantados de compartir cómo GitLab puede ayudarte a trabajar gradualmente en llevar tu proyecto al paraíso del CI/CD.

32 min
01 Jul, 2021

Video Summary and Transcription

GitLab soporta todo el ciclo de DevOps y utiliza herramientas como YesLint, Jest, Docker y Kubernetes. La caché y la validación son desafíos importantes en DevOps. La función de auto DevOps de GitLab simplifica Docker, Kubernetes y Helm. Hay opciones de personalización y opciones avanzadas disponibles en GitLab. El pipeline de GitLab permite optimizar las dependencias de los trabajos y la mejora continua. La duración promedio de los pipelines de construcción de front-end es inferior a 10 minutos para la mayoría de las personas. Ejecutar un proceso de construcción y pipeline en GitLab implica cálculos de trabajos, configuración de runners y lógica oculta. GitLab puede ayudar con la ejecución de front-end en Kubernetes y tiene un visualizador DAG. Lidiar con pruebas inestables en el front-end es un desafío en los pipelines de GitLab.

Available in English

1. Introducción al ciclo y herramientas de DevOps

Short description:

Soy Ilya Klimov de GitLab, un ingeniero senior de frontend. GitLab soporta todo el ciclo de DevOps, enfocándose en verificar, empaquetar y lanzar. En la etapa de Verificación, utilizamos herramientas como YesLint y Jest para la calidad del código y las pruebas. El empaquetado ahora se estandariza con Docker. Por último, hablaré sobre Kubernetes para el lanzamiento.

Hola a todos. Mi nombre es Ilya Klimov. Soy de GitLab, del equipo de importación gestionada. Soy un ingeniero senior de frontend, y me encantan las cosas rápidas. Así que conduzco mucho en mi auto Celes, intento utilizar mi conexión a Internet de un gigabit cuando es posible, y también me encanta GitLab por los tiempos de construcción rápidos. Y aunque los primeros dos obviamente están fuera de contexto de nuestra conferencia, estaré encantado de compartir mi conocimiento con el tercero. Así que en GitLab estamos tratando de apoyarte durante todo el ciclo de DevOps, comenzando desde la creación, donde creas tu código fuente, gestionando problemas, planificando ética, y así sucesivamente. Y terminando con protegerte de diferentes actividades maliciosas y monitoreando la salud de todos tus entornos de producción, puesta en escena, y así sucesivamente. Pero obviamente, hablar sobre todo el ciclo de DevOps llevaría una eternidad para completarse. Así que centrémonos solo en estas tres cosas. Es verificar, empaquetar y lanzar, que básicamente es de lo que se trata la integración continua y la entrega continua será justo después de eso. Entregar las cosas al lugar correcto después del lanzamiento en algún lugar de tu entorno de ejecución real.

Entonces, ¿cuál es el problema aquí? Por lo general, comienza de manera bastante simple. En la etapa de Verificación, en algún lugar, generalmente en el entorno de Node.js, ya que estamos en una conferencia de JavaScript y estamos hablando sobre el entorno de Node.js, incluso si eres un ingeniero de frontend, generalmente ejecutas algunas de tus herramientas favoritas para verificar la calidad del código, ejecutar tus pruebas. Por ejemplo, en GitLab, utilizamos YesLint y Jest para el linting. También mantenemos nuestras propias reglas de linting y para ejecutar pruebas. Hace mucho tiempo, solíamos usar Karma para hacer estas cosas, pero sinceramente, estoy muy feliz de que esos tiempos hayan pasado. Y probablemente introduzcamos más herramientas más adelante. En este paso, la idea principal es asegurarse de que todo vaya bien y que tu código se comporte como se espera. Después de eso, obviamente, necesitamos empaquetar tu código para entregarlo a producción. Y estoy bastante contento de que, bueno, llevo mucho tiempo en el desarrollo de software, más de 10 años. Y recuerdo cuando necesitabas inventar tus propias herramientas de entrega durante mucho, mucho tiempo. Así que ahora, Docker es la forma estándar de hacer las cosas. Y estoy bastante contento de tener eso. Estandarizar las cosas es genial. Y hoy hablaremos mucho sobre cómo hacer las cosas estándar, ya sea para toda la comunidad de JavaScript o solo para tu empresa. Porque cada empresa obviamente tiene su propio enfoque. Así que el último es el lanzamiento. Y aquí, las cosas no son tan estables como en la etapa de empaquetado. Para esta charla, me enfocaré un poco en Kubernetes.

2. Desafíos con las herramientas en el pipeline de DevOps

Short description:

Incluso las herramientas son difíciles. Construir una buena prueba es complejo. Asegurarse de que el código se ejecute correctamente con diferentes versiones de Node.js puede llevar a errores impredecibles. La complejidad del pipeline crece rápidamente a medida que se agregan más herramientas.

que es bastante estándar para ejecutar contenedores Docker. Me doy cuenta de que probablemente tu pipeline o tu futuro pipeline no lo utilice. Probablemente elijas otra forma de ejecutar código o ejecutar contenedores Docker en el metal desnudo, lo que sea. Pero por ahora, empecemos con este. Y el problema aquí es que incluso las herramientas son difíciles. Construir una buena prueba es algo muy complejo, que probablemente valga la pena otra charla. Asegurarse de que tu código se ejecute correctamente cuando tu entorno de desarrollo y tu entorno de integración continua tienen diferentes versiones de Node.js puede ser complicado y puede llevar a errores impredecibles. Un día pasé medio día depurando un bloqueo desconocido, literalmente seis veces, que fue un cambio menor en la tercera parte de la versión, diferente a Node.js. Nunca quiero volver a hacer eso. Pero como puedes ver, estamos agregando cada vez más herramientas en nuestro pipeline, incluso solo para estos tres pasos.

3. Desafíos con Caché, Validación y Registros

Short description:

En un mundo de DevOps, la caché y la validación son dos problemas importantes. La caché de los módulos de Node.js y la entrega de artefactos, como los resultados de las pruebas y los resultados de cobertura, son importantes para mejorar el rendimiento del pipeline. Los registros, como el registro de Docker o el registro de npm, varían según el tipo de lanzamiento.

la complejidad crece muy rápidamente. Pero, bueno, aún piensa que, hey, empecemos con un paso muy simple, hagamos alguna verificación en nuestra integración continua pipeline. Y aquí vienen los problemas. Un día tu jefe viene y dice, hey, tu pipeline funciona bastante lento. Y bienvenido al mundo de uno de los dos mayores problemas de la programación. Ahora, caché y validación. Pero ahora en un mundo de DevOps. Así que comienzas a aprender todas estas cosas sofisticadas sobre cómo cachear, por ejemplo, los módulos de Node.js entre tus pasos de construcción para evitar ejecutar npm install o YAR install en cada pestaña. Cómo entregar artefactos, cosas que deben persistir a través de los pipelines, por ejemplo, resultados de pruebas, resultados de cobertura, si haces pruebas de integracióntesting, podría ser una captura de pantalla de cosas fallidas. Y el registro. Y el registro puede ser diferente. El registro de Docker puede ser para tus contenedores de Docker. Si estás lanzando algo a npm, podría ser como un

4. GitLab's Auto DevOps Feature

Short description:

GitLab puede ayudarte con la complejidad de Docker, Kubernetes y Helm en la primera etapa del ciclo de DevOps. La función de auto DevOps en GitLab CI es poderosa y permite una configuración sencilla. Al importar un repositorio del mundo real y utilizar el pipeline de auto DevOps por defecto, puedes construir y probar automáticamente tu aplicación. GitLab utiliza el paquete de compilación de Heroku para proporcionar diversas funciones como verificaciones de calidad de código, análisis de seguridad y más. Las características disponibles dependen del nivel de tu solución de GitLab. GitLab también tiene una herramienta de calidad de código automática que detecta YesLint y ejecuta comprobaciones específicas para ello. La configuración cero es la predeterminada, pero es posible personalizarla adicionalmente.

registro privado de npm o registro público de npm, las cosas son diferentes. Pero un día, estás comenzando con las primeras cosas. Así que tienes un pequeño paso elegante, y el jefe viene y dice, hey, ya sabes, las pruebas automatizadas no son suficientes. Quiero que una persona de aseguramiento de calidad revise los cambios de la subrama y verifique que todo vaya bien. En GitLab, lo llamamos aplicaciones de revisión. Algo así como una aprobación manual. Y hola, toda esta complejidad, Docker, Kubernetes, Helm, lo que sea, ya está llegando a la primera etapa. Y veamos cómo GitLab podría ayudarte con eso.

Así que, comencemos con el primer paso, que es el auto DevOps. Hablando francamente, el poder de GitLab CI fue la principal razón por la que me uní a GitLab hace mucho, mucho tiempo. Ya era un gran fanático de él tres años antes de unirme a GitLab, y estoy muy contento con la función de auto DevOps, e incluso feliz de que, como ingeniero de front-end, haya contribuido en Git. Así que, supongamos que simplemente importas algún repositorio del mundo real. He elegido el ejemplo de aplicación del mundo real de Vue solo porque mi pila principal es Vue.js, y hago clic en la herramienta de auto pipeline de DevOps predeterminada en la configuración del nuevo proyecto, y la magia sucede. Tienes este pipeline, que automáticamente tendrá pasos de construcción, calidad de código, pruebas de YesLint, y así sucesivamente. ¿Qué está sucediendo? La razón es, probablemente, si llevas suficiente tiempo en el desarrollo de JavaScript, probablemente hayas implementado tu aplicación en Heroku y conozcas toda esa magia. Simplemente haces git push, y todo funciona. Bueno, estamos aprovechando un poco esa oportunidad. Utilizamos el paquete de compilación de Heroku para comprender cómo construir tu aplicación y proporcionarte toneladas de cosas diferentes. Podemos probar automáticamente que no estés filtrando secretos, o tal vez olvidaste eliminar tu clave de Amazon Web Services del repositorio de Git. Te lo haremos saber. Tal vez tengas un código deficiente en calidad, o tal vez tu código de front-end no sea tan seguro. Tenemos toneladas de cosas para producir, que aparecerán automáticamente en tu pipeline. Solo para que sepas que lo que tendrás dependerá en gran medida del nivel que tengas en tu solución independiente o SaaS de Git. Cuanto más pagues, obviamente, más cosas obtendrás. Por ejemplo, como mencioné, contribuí a la herramienta de calidad de código automática, que detectará automáticamente YesLint y ejecutará varias comprobaciones específicas de YesLint. YesLint de seguridad, YesLint relacionado con react, y eso contribuyó a la selección adecuada de la versión de YesLint. Si ya tienes una configuración de YesLint en tu repositorio, también ejecutaremos tus comprobaciones, obviamente. Pero obviamente, la configuración predeterminada no es suficiente para todos. La configuración cero es genial. Todos lo hacen. Cada herramienta de compilación, cada herramienta que quiere tener éxito,

5. Customization and Advanced Options

Short description:

AutoDesarrollo permite una rápida prueba de integración continua. La personalización es sencilla con la configuración de variables de entorno. Puedes configurar los pasos de construcción, desactivar ciertos pasos y habilitar/deshabilitar aplicaciones de revisión. GitLab fomenta las contribuciones y el aprendizaje. Utiliza la configuración de auto Desarrollo y la interfaz de usuario de GitLab como inspiración. Considera el proyecto untampermylogfile para la seguridad. Explora frontend.GitLab.CI.YAML en el repositorio principal de GitLab para opciones avanzadas y optimización de velocidad.

lo hace. Y AutoDesarrollo te permitirá tener rápidamente una idea de lo que significa integración continua para ti. Así que el siguiente paso es, obviamente, la personalización. No quiero entrar en detalles porque sería como leer 10 páginas de documentación, pero es extremadamente sencillo. Si sabes cómo configurar tu aplicación con variables de entorno, sabes cómo configurar DevOps. Puedes configurar cada paso de construcción y desactivar ciertos pasos en nuestro pipeline de DevOps. Puedes habilitar o deshabilitar aplicaciones de revisión si quieres que se construyan para cada repositorio. Si quieres tener aplicaciones de revisión, necesitarás la integración del clúster de Kubernetes, por cierto. Y esto es bastante sencillo, pero un día eso no será suficiente y querrás ensuciarte las manos y contribuir con algo que probablemente no hayamos tenido en cuenta en nuestro pipeline de auto DevOps. Recuerda el lema de GitLab, todos pueden contribuir, y estaremos encantados si abres una solicitud de fusión si encuentras algún problema o posible mejora. Y no quiero detenerme aquí en el aprendizaje, necesitas, hey, necesitas aprender la nueva configuración YAML y puedes leer la documentación, es realmente genial, créeme, pero a veces cada uno de nosotros necesita una fuente de inspiración. Te sugiero que hagas solo tres cosas. En primer lugar, echa un vistazo a la configuración de auto DevOps que has comenzado. Te permitirá saber cómo invocamos ciertas cosas. Todo es de código abierto en tu proyecto y te dará un buen punto de partida. Si solo quieres elegir algo menor, simplemente copia, pega, ajusta y ya eres genial. Y probablemente con dos proyectos que están completamente en GitLab, uno de ellos es GitLab UI. GitLab UI es nuestra biblioteca de interfaz de usuario y tenemos un pipeline muy pequeño allí que simplemente ejecuta pruebas, lanza a NPM y realiza una integración visual, comparando las capturas de pantalla, y siempre uso este archivo YAML como fuente de inspiración. Porque, por ejemplo, ¿alguna vez has pensado que cada vez que un colaborador, interno o externo, te da una actualización en tu archivo de registro de YARN o archivo de registro de NPM, podría actualizar este archivo para apuntar a una versión maliciosa o incluso a un código malicioso de terceros? ¿Realmente quieres verificar esto manualmente con tus ojos? Obviamente no. Y por ejemplo, hace unos días, cuando volví a mirar este archivo preparándome para la charla, descubrí el proyecto untampermylogfile, que se ocupa de esto, verificando con los registros de NPM y asegurándose de que el archivo de registro te esté diciendo la verdad y no haya sido alterado de manera maliciosa. Y si quieres ir a algo realmente, realmente increíble, solo revisa nuestro repositorio principal de GitLab, frontend.GitLab.CI.YAML. Lo mantenemos separado allí. Y, bueno, realmente roza la locura. Si no lo sabes, aproximadamente el 60% del tiempo, los corredores de GitLab CI SaaS están construyendo GitLab. Así que realmente queremos hablar de velocidad. Bueno, solo piensa cuánto dinero podríamos ahorrar si pudiéramos hacer que nuestras tuberías se ejecuten más rápido y cuán felices serán tus desarrolladores al recibir comentarios más rápidos. Así que hablemos de DAG. Este es nuestro pipeline de GitLab. Ni siquiera está completo. La etapa de prueba

6. Optimización de las dependencias de trabajo en el pipeline

Short description:

Y por lo general, se ejecuta uno por uno. Estamos dividiendo nuestros trabajos por etapas. Preparar, construir, imágenes, arreglos, prueba. Nuestro trabajo que ejecuta pruebas necesita un trabajo de arreglos de front-end. YesLint y GraphQL Verify son dos trabajos. YesLint se puede mover a una etapa anterior, pero se requiere que esté en la etapa de prueba. La nueva característica de grafo acíclico dirigido permite especificar las dependencias de trabajo. El pipeline ahora tiene diferentes dependencias entre sí.

es mucho más grande. Y por lo general, se ejecuta uno por uno. Esta es una filosofía que todos tienen. Estamos dividiendo nuestros trabajos por etapas. Entonces, la primera etapa se ejecuta primero, esperando a que todos los trabajos se completen después de eso, la segunda, y así sucesivamente. Obviamente, este es nuestro flujo. Preparar, construir, imágenes, arreglos, prueba. ¿Podríamos hacer que se ejecute más rápido teóricamente? Sí, por supuesto. Acerquémonos. Y si miras aquí, obviamente, nuestro trabajo justo, que ejecuta pruebas, necesita un trabajo de arreglos de front-end, que está cortado aquí. Pero créeme, esta es la segunda palabra, arreglos, aquí. Y este trabajo obviamente genera algunos datos de mock que son consumidos por nuestras pruebas. Entonces, estos dos trabajos están obviamente en su lugar y son una dependencia fuerte. Se necesitan mutuamente. Pero echemos un vistazo a estos trabajos. YesLint y GraphQL Verify. Para YesLint, solo necesitamos un código. No hay razón para esperar algo. Entonces, probablemente podríamos moverlo a la etapa anterior. No me gusta. No me gusta porque está aplastando toda la idea. Obviamente, YesLint está en la etapa de prueba y se requiere que esté allí. Entonces, ¿qué hacer? Y aquí viene al rescate nuestra característica aún bastante nueva. No tan nueva brillante, pero nueva grafo acíclico dirigido, que te permite, después de eso, meter las manos en la etapa anterior y entender qué es un trabajo, cuáles son los nombres de los trabajos. Simplemente especifica, hey, este trabajo, YesLint como una fuerza, no necesita nada. Entonces, podría ejecutarse inmediatamente lo antes posible. Y este trabajo necesita que se completen nuestros arreglos de front-end. Así que, por favor, espera esto y comienza nuestro trabajo lo antes posible. Entonces, parte de nuestro pipeline ahora se ve de esta manera. Y, bueno, es bastante divertido ver, y es bastante divertido entender lo rápido que podríamos ir con esto. Como puedes ver, hay muchas dependencias diferentes entre sí.

7. Optimización del Pipeline y Mejora Continua

Short description:

Utilizamos la interfaz de GitLab para diversas tareas, como ejecutar pruebas lo antes posible y desplegar el trabajo de revisión. Las compilaciones de imágenes de Docker activan actualizaciones automáticas de capturas de pantalla y escaneo de contenedores. El uso de un DAG en GitLab simplifica el pipeline y lo hace más fácil de descubrir. Considera la personalización completa del pipeline o contribuir a la plantilla de auto DevOps para tu empresa. La mejora del pipeline es un proceso continuo. No dudes en contactarnos en Twitter si tienes alguna pregunta o sugerencia. ¡Gracias por unirte a nosotros!

Por ejemplo, no podíamos calcular la cobertura antes de que se completaran todas nuestras pruebas, pero queremos ejecutarlas lo antes posible. Por ejemplo, queremos ejecutar las pruebas solo después de entender cuáles pruebas queremos ejecutar. Estamos invirtiendo mucho tiempo en no probar cosas que definitivamente no han cambiado y en muchos otros enfoques. Si aún piensas que no lo necesitas, parece ser otro campo para mi pequeño proyecto. Aún lo utilizamos en la interfaz de GitLab y mira, es bastante simple y aún brillante. Por ejemplo, el trabajo de revisión, que permite a las personas verificar las cosas en una URL separada y desplegar, se ejecutará tan pronto como se construya nuestro storybook. Sí, probablemente podríamos hacer un mejor trabajo al colocar las palabras en una línea, pero hey, estamos mejorando constantemente. Lo mismo ocurre tan pronto como se construye una imagen de Docker, podríamos ejecutar la actualización de capturas de pantalla, que se actualizará automáticamente, este es un trabajo manual. Podemos realizar una verificación visual para asegurarnos de que nuestra captura de pantalla se vea igual y un escaneo de contenedores para asegurarnos de que no se esté ejecutando nada malicioso. Esto sigue siendo impresionante y se siente como una mejora significativa, porque es tan fácil, al menos para mí, entender el enfoque de las necesidades. Anteriormente, hace mucho tiempo, cuando no estaba trabajando en GitLab, dividía mis cosas en muchas etapas diferentes solo para asegurarme de que podía poner algo en las cosas que tenían sentido para mí. Mira tu código, tal vez también tengas todo esto, como tener la primera etapa, como prueba uno, prueba dos, prueba tres, prueba cuatro, deshazte de eso. Con un DAG, puedes hacer que tu proceso sea fluido y bastante fácil de descubrir, porque es un gráfico, a todos los ingenieros de software les encanta un gráfico, creo. Si hay algo que probablemente deberías probar en GitLab, esto es, obviamente, el DAG, 10 de 10 puntos, lo recomiendo.

Entonces, ¿qué hacer a continuación? Probablemente lo hayas optimizado y estés satisfecho con los resultados, y hay una cosa más por hacer. Una cosa más por hacer depende de lo que quieras, en realidad. Probablemente podrías optar por un pipeline personalizado completo, que es lo que estamos haciendo actualmente en GitLab, porque a veces queremos tareas inusuales y requisitos habituales y podrías querer ser un verdadero ingeniero de DevOps, pero hay otra opción que te sugiero considerar. Si estás ejecutando múltiples proyectos en tu empresa, por ejemplo, mi empresa anterior era una empresa de externalización, por lo que creamos muchos proyectos bastante similares, solo descubre en nuestra documentación cómo puedes contribuir a una plantilla de auto DevOps específica para tu empresa, asumiendo que estás ejecutando una versión independiente de GitLab. Y si haces esto, probablemente podrías ahorrar suficiente tiempo para otras personas en tu empresa. Así que recuerda que la mejora del pipeline es un proceso constante y no una tarea única. Cada vez que eches un vistazo a tu pipeline, descubre las cosas que van lentas. Y si tienes alguna pregunta, alguna sugerencia, no dudes en contactarme en Twitter, Xanth-UA. Y nunca dejes de mejorar tus flujos. Gracias. Deja el micrófono, Ilja. Qué gran charla. Muchas gracias por unirte a nosotros. Es realmente excelente.

8. Duración Promedio del Pipeline de Construcción de Front-End

Short description:

¿Cuál es la duración promedio de tu pipeline de construcción de front-end? La mayoría de las personas tienen un pipeline de menos de diez minutos, ya sea porque tienen un proyecto pequeño o porque su pipeline está súper optimizado. Sin embargo, hay un aumento gradual en el rango de 10 a 30 minutos.

Damos la bienvenida a Ilja para responder la pregunta que nos hizo a todos antes de la charla. Entonces, ¿cuál es la duración promedio de tu pipeline de construcción de front-end? Y veo estos resultados y en realidad voté de diez a treinta minutos debido a esos dos minutos, ¿verdad? Muchas veces toma 12 o 13 minutos, así que caigo en el segundo grupo y no parezco tan avanzado. Entonces, ¿estos números te sorprenden, Ilja? ¿La mayoría de las personas tienen un pipeline de menos de diez minutos? Sí, porque normalmente espero esto, ya sabes, Node.js no es tan rápido para iniciar como de costumbre, y tener el pipeline de menos de diez minutos significa que tienes un proyecto bastante pequeño, lo cual es genial, personalmente me gustan mucho las startups, o tu pipeline está súper optimizado porque, hey, todo en nuestro mundo de Javascript, desafortunadamente, no es tan rápido como debería ser. Así que sí, estoy un poco sorprendido, pero me gusta, ya que estamos viendo los resultados en vivo.

9. Duración del Pipeline y Adopción de CI

Short description:

No muchas personas se han unido al club de más de 30 minutos para los pipelines. Los pipelines pueden variar desde 40 minutos hasta seis horas, dependiendo de la suerte y la escala. Las categorías de menos de 10 minutos y de 10 minutos a 30 minutos están ambas en un 40%, lo que indica que la mayoría de las personas están utilizando CI.

Veo que la gente está aumentando lentamente la segunda opción, de diez minutos a 30 minutos, sí. Bueno, y estoy realmente feliz de que no muchas personas se hayan unido a este club de más de 30 minutos hola desde GitLab. Tenemos, como, pipelines de 40 minutos a seis horas, dependiendo de tu suerte y la escala. Así que, sí, ya conoces esa historia, como, okay, probablemente me tome un café mientras se ejecuta el pipeline, así que para GitLab, probablemente será mucho café. Veo que ahora los de menos de 10 minutos y los de 10 minutos a 30 minutos están cabeza a cabeza, ambos están en un 40%. Así que todavía hay personas que ni siquiera están utilizando CI. Supongo que estos números son buenos. Lo suficientemente buenos, al menos sabemos que la gran mayoría de las personas realmente lo están utilizando.

10. Running a Build and Pipeline Process

Short description:

Recordemos cuál es el tiempo de espera para ejecutar una compilación. Preguntas de nuestros espectadores. Alexa pregunta, ¿qué sucede en segundo plano cuando se activa un pipeline, especialmente con los pipelines de GitLab? Sí, seguro. Es bastante simple y a la vez complicado. Internamente en GitLab tienes el archivo .gitlab.CI.yaml que especifica o no especifica ciertos requisitos para la máquina de compilación. GitLab marca, como, hey, aquí está el pipeline. Dependiendo de ciertas condiciones, quién activó el trabajo, por qué se activó el trabajo, y así sucesivamente, calcula qué trabajos se ejecutarán en este pipeline. Después de eso, todos los runners están enviando señales a GitLab. Entonces, cada runner, puede ser el mismo o no, dependiendo de cuántos tengas, está clonando tu repositorio y luego ejecutando la descripción del trabajo. El pipeline es grande, está compuesto por los trabajos. También, una cosa que probablemente la gente a veces no se da cuenta, es que incluso si estás utilizando la versión gratuita en gitlab.com y te quedas sin nuestro límite, creo que son 2000 minutos de CI por mes para la versión gratuita, puedes comprar minutos o simplemente configurar un runner conocido en cualquier PC virtual o de hardware que tengas, registrarlo en gitlab.com y aún podrás compilar tu proyecto en tu hardware o en tu, lo que prefieras, Amazon, Google Cloud, Azure, y seguirás estando en la versión gratuita. Así que siempre puedes tener el control de tu hardware. Por qué digo que es complicado es porque creo que suena bastante fácil, pero en realidad hay mucha lógica oculta, como reintentos, entender que los trabajos están bloqueados porque a todos les encantan los ciclos infinitos, reintentar el trabajo si el runner falla, tener cachés compartidas para que cuando tu caché esté en un runner, se pueda obtener de forma segura desde otro. Es una parte importante escrita en lenguaje Go y Ruby, y hay mucho código oscuro, al menos desde mi perspectiva de front-end, que une todo esto. Entendido. Esa es una excelente respuesta.

CI. Recordemos cuál es el tiempo de espera para ejecutar una compilación. Como, recuerdo que solía ser siempre un problema, donde, como, había compilaciones realmente largas. Nunca recuerdo cuánto tiempo dura. Así que, okay. Preguntas de nuestros espectadores. Alexa pregunta, ¿qué sucede en segundo plano cuando se activa un pipeline, especialmente con los pipelines de GitLab? Sí, seguro. Es bastante simple y a la vez complicado. Internamente en GitLab tienes el archivo .gitlab.CI.yaml que especifica o no especifica ciertos requisitos para la máquina de compilación. Porque para ciertos pasos, podrías, por ejemplo, no es común para el front-end, pero, hey, a nuestro webpack a veces le gusta consumir mucha memoria. Así que podrías tener diferentes máquinas con runners instalados que consumirán, que proporcionarán diferentes capacidades, tal vez diferentes CPUs, diferentes cantidades de memoria disponible o lo que sea. Entonces, GitLab marca, como, hey, aquí está el pipeline. Dependiendo de ciertas condiciones, quién activó el trabajo, por qué se activó el trabajo, y así sucesivamente, calcula qué trabajos se ejecutarán en este pipeline. Después de eso, todos los runners están enviando señales a GitLab. Como, hey, estoy libre, como McDonald's y diciendo, hey, estoy libre, ¿me podrías dar un trabajo? El runner está clonando la descripción del trabajo y hace exactamente lo que se describe allí. Entonces, cada runner, puede ser el mismo o no, dependiendo de cuántos tengas, está clonando tu repositorio y luego ejecutando la descripción del trabajo. El pipeline es grande, está compuesto por los trabajos. También, una cosa que probablemente la gente a veces no se da cuenta, es que incluso si estás utilizando la versión gratuita en gitlab.com y te quedas sin nuestro límite, creo que son 2000 minutos de CI por mes para la versión gratuita, puedes comprar minutos o simplemente configurar un runner conocido en cualquier PC virtual o de hardware que tengas, registrarlo en gitlab.com y aún podrás compilar tu proyecto en tu hardware o en tu, lo que prefieras, Amazon, Google Cloud, Azure, y seguirás estando en la versión gratuita. Así que siempre puedes tener el control de tu hardware. Por qué digo que es complicado es porque creo que suena bastante fácil, pero en realidad hay mucha lógica oculta, como reintentos, entender que los trabajos están bloqueados porque a todos les encantan los ciclos infinitos, reintentar el trabajo si el runner falla, tener cachés compartidas para que cuando tu caché esté en un runner, se pueda obtener de forma segura desde otro. Es una parte importante escrita en lenguaje Go y Ruby, y hay mucho código oscuro, al menos desde mi perspectiva de front-end, que une todo esto. Entendido. Esa es una excelente respuesta.

QnA

Running Front-End in Kubernetes and DAG Visualizer

Short description:

¿Vale la pena ejecutar el front-end en Kubernetes? Depende de lo que estés optimizando, ya sea el costo o la velocidad. Kubernetes se escala bien desde proyectos pequeños hasta configuraciones enormes como GitLab. Pero si tu proyecto es pequeño, GitLab aún puede ayudarte. Puedes optimizar tu pipeline según tu etapa actual. El costo no es un problema. El visualizador DAG está disponible en las versiones Enterprise de GitLab introducidas en la versión 12.2 y posteriores.

Entendido. Esa es una excelente respuesta. Pregunta de Vritr. ¿Vale la pena ejecutar el front-end en Kubernetes? Dado que no hay un CDN, debes escalar la infraestructura todo el tiempo a medida que aumentan las cargas de trabajo y también puedes encontrarte con limitaciones de E/S de nodo y sobrecarga, etc. Teniendo en cuenta el costo más el tiempo y la configuración simple de S3 en CloudFront, ¿qué harías? ¿Lo harías? ¿Configurarías un front-end en Kubernetes? Oh, es una buena pregunta y realmente depende de lo que estés optimizando. Ya sea el costo, me refiero al dinero, o la velocidad. Es muy difícil responder sin problemas precisos. Lo que mencioné en mi charla, y me gustaría insistir nuevamente, es que esta configuración con Kubernetes y demás es simplemente porque se escala bien en términos de infraestructura, desde proyectos pequeños hasta configuraciones enormes como GitLab. Pero esto no significa que si decides abandonar Kubernetes porque tu proyecto es bastante pequeño, esto no signifique que GitLab no pueda ayudarte. Puedes hacer todo en tu pipeline, y para la suma de mis proyectos personales, solo estoy construyendo el código, y ni siquiera uso Docker para ejecutarlo, solo copio los archivos de construcción resultantes al servidor y lo ejecuto. Bastante desordenado y nunca lo mostraría en mi currículum como una buena configuración de infraestructura, pero vamos, estamos hablando de construir infraestructura paso a paso, así que siéntete libre de optimizar lo que necesites en la etapa actual. Si tienes dinero de sobra, probablemente ya puedas ir a las cosas que llamo la sangre enterprise, pero si no, siéntete libre de hacerlo tan sucio como quieras. No te lo impediremos. Sí, el costo no es un problema. Veo que también has comenzado a hacer un stand up aquí, y estoy bromeando. Entonces Louise pregunta, ¿en qué versiones de GitLab enterprise está habilitado el visualizador DAG? Está en todas partes, y no estoy seguro, necesito verificar rápidamente en la documentación de GitLab. Podría estar detrás de una bandera de características y no, creo que ya está disponible. Se introdujo en GitLab 12.2 y la bandera de características se eliminó en GitLab 12.10. Y esto es como, mi matemática y el tiempo son difíciles. Fue hace bastante tiempo, aproximadamente hace 10 meses, así que debería estar disponible para cualquier GitLab bastante reciente.

Challenges with Flaky Tests in GitLab Pipelines

Short description:

La parte más difícil de los pipelines de GitLab es lidiar con pruebas inestables en el frontend. Debido a la naturaleza asíncrona del desarrollo frontend, es fácil escribir pruebas que no esperan ciertas condiciones, lo que lleva a pruebas fallidas cuando el entorno de CI no está sincronizado. Desafortunadamente, no hay una solución perfecta para garantizar la confiabilidad de las pruebas, y puede ser frustrante cuando las pruebas fallan intermitentemente.

De acuerdo, muy bien. Así que, solo una pregunta más. Ahora es el momento, gente. Todavía tenemos a Ilya aquí con nosotros, así que dejen sus preguntas en el DevOps Talk Q&A, y no olviden que Ilya estará disponible en su sala de conferencias y en el chat espacial, así que definitivamente pueden hablar con él allí. Pero una pregunta más. Entonces, ¿cuál dirías, Ilya, que es la parte más difícil de los pipelines de GitLab, si tuvieras que pensarlo? Oh, la parte más difícil de los pipelines de GitLab son las pruebas inestables, si hablamos del frontend, porque, debido a la naturaleza asíncrona del frontend, es muy fácil escribir una prueba que no espera algo, sino que simplemente confía en que algo en tu entorno de CI es lo suficientemente lento, o incluso lo suficientemente rápido. Y eso significa que estás cambiando algunas cosas en la configuración de CI, y de repente ves muchas pruebas fallidas, y piensas, hey, probablemente arruiné mi configuración, pero no es así. Desafortunadamente, no tengo una solución perfecta para asegurarme de que tus pruebas sean correctas, y esto no es realmente una pregunta sobre pipelines, pero para mí esta es la parte más oscura de cualquier cosa relacionada con el frontend en los pipelines de GitLab. Porque, bueno, cuando falla cada vez, sabes qué hacer. Cuando falla a veces, todos están molestos y, hey, nadie está feliz cuando dices, oh, falló. Intentemos volver a intentarlo y esperemos lo mejor.

Entiendo. Gente, ahora es el momento. ¿Alguna pregunta final para Ilya? Esperaremos unos segundos. A la gente le lleva tiempo. Muchos dicen, gracias. Excelente charla. Buena charla. Gracias. Muy útil. Así que, deberías estar feliz, Ilya. Tuviste una charla realmente genial. Así que, felicidades por una sesión realmente excelente. Creo que vamos a terminar. Muchas gracias por estar con nosotros y compartir tus conocimientos sobre GitLab. Ilya estará disponible en la sala de conferencias y en el chat espacial y en Discord. No dudes en comunicarte y hacer más preguntas que puedas tener y que no hayan sido respondidas en vivo durante la sesión. Muchas gracias. Gracias.

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
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 2024DevOps.js Conf 2024
25 min
End the Pain: Rethinking CI for Large Monorepos
Scaling large codebases, especially monorepos, can be a nightmare on Continuous Integration (CI) systems. The current landscape of CI tools leans towards being machine-oriented, low-level, and demanding in terms of maintenance. What's worse, they're often disassociated from the developer's actual needs and workflow.Why is CI a stumbling block? Because current CI systems are jacks-of-all-trades, with no specific understanding of your codebase. They can't take advantage of the context they operate in to offer optimizations.In this talk, we'll explore the future of CI, designed specifically for large codebases and monorepos. Imagine a CI system that understands the structure of your workspace, dynamically parallelizes tasks across machines using historical data, and does all of this with a minimal, high-level configuration. Let's rethink CI, making it smarter, more efficient, and aligned with developer needs.
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.
React Advanced Conference 2022React Advanced Conference 2022
16 min
Automated Performance Regression Testing with Reassure
As developers we love to dive into performance metrics, benchmarks, compare one solution to another. Whether we enjoy it or not, we’re often required to fix performance issues in our React and React Native apps. But this process is not sustainable and prone to regressions, especially as the app and team grow. What’s worse, those issues are often discovered by your users, making their experience miserable. In my talk I’ll introduce you to Reassure—a performance regression testing library for React and React Native— which happens to be a missing piece in our automated testing and performance suites. Spotting problems before they hit production.
DevOps.js Conf 2021DevOps.js Conf 2021
9 min
How to Get CI/CD Right in 2021: A Guide to CI and CD
Software delivery is a top priority for organizations that own software, yet it remains one of the most challenging problems enterprises face today. Continuous integration (CI) and continuous delivery (CD) are software practices that allow organizations and teams to deliver code to customers quickly, safely, and repeatedly. Whether it's to improve development, operations, or security, CI/CD pipelines give engineers and teams more time to work on things that matter and less time struggling with the risk, standards, and velocity of deployments. Join this session to learn about the components of CI/CD and how to build and scale pipelines for the future.

Workshops on related topic

DevOps.js Conf 2022DevOps.js Conf 2022
76 min
Bring Code Quality and Security to your CI/CD pipeline
WorkshopFree
In this workshop we will go through all the aspects and stages when integrating your project into Code Quality and Security Ecosystem. We will take a simple web-application as a starting point and create a CI pipeline triggering code quality monitoring for it. We will do a full development cycle starting from coding in the IDE and opening a Pull Request and I will show you how you can control the quality at those stages. At the end of the workshop you will be ready to enable such integration for your own projects.
DevOps.js Conf 2022DevOps.js Conf 2022
155 min
Powering your CI/CD with GitHub Actions
Workshop
You will get knowledge about GitHub Actions concepts, like:- The concept of repository secrets.- How to group steps in jobs with a given purpose.- Jobs dependencies and order of execution: running jobs in sequence and in parallel, and the concept of matrix.- How to split logic of Git events into different workflow files (on branch push, on master/main push, on tag, on deploy).- To respect the concept of DRY (Don't Repeat Yourself), we will also explore the use of common actions, both within the same repo and from an external repo.
DevOps.js Conf 2022DevOps.js Conf 2022
124 min
Debugging JavaScript Apps in CI/CD
Workshop
- Causes of failed builds in CI/CD pipelines- Approaches to debugging (reviewing logs, accessing environments, reproducing issues)- Debugging application-related causes (failing tests, failed application builds)- Debugging pipeline-related causes (pipeline setup, environment issues, container issues)
DevOps.js Conf 2021DevOps.js Conf 2021
149 min
CI/CD 101 with CircleCI
Workshop
Continuous Integration and Continuous Delivery/Deployment (CI/CD) concepts are increasingly adopted many technology organizations and teams. CI/CD enables teams to establish processes that increase velocity, collaboration and quality of their codebase. CI/CD enables developer & operations teams to break down unnecessary silos and gain a deeper knowledge of their respective arenas.
In this workshop the participants will be introduced to the basic fundamentals of Continuous Integration and Continuous Delivery/Deployment. Participants will learn the core principles of CI/CD and have the opportunity to reinforce what they’ve learned in a hands on workshop featuring the CircleCI platform. The workshop will demonstrate CI/CD build configuration, code commits, commit builds, code testing and packaging. The participants will leave with a hands-on experience and understanding of what it takes to CI/CD.
Table of contents- Introduction to the topic of CI/CD, and motivation for it- How different kinds of JavaScript projects are built and deployed (from static sites to APIs)- Overview of common manual steps & how we might automate them- Implementing a CI/CD pipeline from 'scratch'- Overview of CircleCI orbs- Testing across multiple versions of Node- Debugging builds with SSH- Caching dependencies- Security / vuln scanning- Deploying to various outlets
Prerequisites- Code and git installed- GitHub account
github.com/CircleCI-Public/cicd-workshop-js