Construye tu Pipeline de JS de forma incremental con GitLab

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.

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,

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.

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.