1. Introducción al ciclo y herramientas de DevOps
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
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
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
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
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
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
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
¿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
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
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.
Running Front-End in Kubernetes and DAG Visualizer
¿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
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.
DevOps.js Conf 2022
React Advanced Conference 2022
TestJS Summit 2021
Comments