GitLab CI/CD

Hola, soy Alex de DEV STORIES DOT EU. GitLab CI/CD, episodio 1 de 14. Muchos equipos de ingeniería dependen de procesos de release desordenados y sin documentar que solo una persona entiende de verdad. El camino real hacia producción permanece invisible hasta que algo falla. El paradigma punto gitlab guion c i punto yml cambia esto al traducir todo tu ciclo de vida de build y release en un gráfico secuencial y transparente. GitLab CI/CD es el sistema integrado de integración continua y continuous deployment de GitLab. Se controla por completo mediante un único archivo de configuración llamado punto gitlab guion c i punto yml. Colocas este archivo en el directorio raíz del repositorio de tu proyecto. Como se hace commit junto con el código de tu aplicación, tu proceso de deploy está controlado por versiones, es auditable y accesible para cualquier desarrollador que mire el repositorio. Cuando haces push de un commit que contiene este archivo, GitLab lo detecta inmediatamente y dispara un pipeline. Un pipeline es la arquitectura de nivel superior de tu proceso de CI/CD. Se compone de dos componentes principales: jobs y stages. Los jobs dictan qué es lo que realmente pasa. Un job contiene los comandos de shell o scripts específicos necesarios para ejecutar una tarea, como compilar código fuente, formatear texto o mover archivos a un servidor. Los stages dictan cuándo se ejecutan esos jobs. Organizas los jobs en stages para controlar el flujo cronológico de ejecución. Imagina un pipeline estándar con tres stages. En la parte superior de tu archivo de configuración YAML, declaras tus stages en el orden exacto en el que quieres que se ejecuten: build, test y deploy. Debajo de esa lista, defines tus jobs individuales y los asignas a esos stages definidos. Empiezas escribiendo un job llamado build guion job y lo asignas al stage de build. Su script le dice al sistema que compile tu aplicación. Luego, escribes un job llamado test guion job, lo asignas al stage de test y le pasas el comando para ejecutar tu test suite. Finalmente, escribes un job deploy guion prod, lo vinculas al stage de deploy y le das las instrucciones para hacer push de la aplicación compilada a tu entorno de producción. Aquí está la clave. GitLab procesa estos stages estrictamente en secuencia. El pipeline empieza con el stage de build. El sistema ejecuta tu job de build. Si ese job termina con éxito, el pipeline avanza automáticamente al stage de test y ejecuta el job de test. Si los tests pasan, avanza al stage de deploy. Este orden estricto actúa como un quality gate definitivo. Si un job falla en cualquier punto, por ejemplo, si un unit test falla durante el stage de test, todo el pipeline se detiene. El stage de deploy nunca se ejecutará, lo que significa que el código roto no puede llegar a producción. Como esta lógica se declara claramente en el archivo YAML, la interfaz de usuario de GitLab la traduce en un gráfico visual del pipeline. Cualquiera en tu equipo puede ver un commit, mirar el gráfico y entender al instante exactamente dónde está el código en el pipeline, qué stage tuvo éxito y precisamente dónde ocurrió un fallo. El punto fuerte de este paradigma es la centralización. Al definir los stages y jobs en un único archivo raíz, tu secuencia de deploy deja de ser un misterio y se convierte en un proceso legible y repetible que vive exactamente en el mismo lugar que tu código. Si te gustaría apoyar el programa, puedes buscar DevStoriesEU en Patreon. Eso es todo por este episodio. ¡Gracias por escuchar y sigue programando!

Hola, soy Alex de DEV STORIES DOT EU. GitLab CI/CD, episodio 2 de 14. Pasas horas escribiendo un archivo de configuración de pipeline perfecto, haces commit y esperas. Pero no pasa nada. Tu pipeline es completamente inútil sin un motor de cómputo esperando para recoger esas instrucciones. Aquí es donde entran en juego los GitLab Runners y Executors. Existe la idea errónea de que la propia aplicación de GitLab ejecuta tus build scripts. No es así. GitLab gestiona el repositorio y rastrea el estado de tus pipelines, pero delega estrictamente la ejecución real. Un GitLab Runner es una aplicación independiente que funciona como agente. Hace polling continuamente a la instancia de GitLab, preguntando si hay jobs pendientes que esté autorizado a gestionar. Cuando encuentra uno, hace pull del payload del job, ejecuta los comandos y envía los logs y resultados de vuelta a GitLab. Tienes dos opciones principales para obtener estos agentes. El camino más fácil es usar GitLab-hosted runners. Estos se gestionan por ti en GitLab SaaS y cubren entornos comunes como Linux, macOS y Windows. Sin embargo, a menudo necesitas una configuración personalizada. Quizás tu build requiera hardware especializado, como una GPU específica, o necesite acceso a una red interna privada. En ese caso, usas self-managed runners. Instalas la aplicación del runner en tu propia infraestructura. Puedes darles un scope amplio a estos self-managed runners en toda una instancia de GitLab, compartirlos entre un grupo de proyectos relacionados, o restringirlos a un único proyecto específico. Una vez que un runner recoge un job, necesita saber exactamente cómo y dónde ejecutar los comandos. Esto lo define el executor. El executor dicta el entorno de ejecución específico para el job. Dos de los tipos más comunes son el shell executor y el Docker executor. El shell executor es sencillo. Ejecuta el job directamente en el sistema operativo de la máquina host usando una terminal shell estándar, como Bash o PowerShell. Por este motivo, todas las dependencias deben estar preinstaladas en esa máquina host. El Docker executor funciona de manera diferente. Levanta un container nuevo y aislado para cada job, ejecuta los scripts en su interior y lo destruye después. Esto garantiza un entorno completamente limpio cada vez. Veamos un escenario concreto registrando un self-managed project runner localmente usando un shell executor. Primero, vas a la configuración específica de tu proyecto en GitLab y creas un nuevo runner. GitLab generará un token de autenticación único. A continuación, instalas la aplicación GitLab Runner en tu máquina local. Desde tu terminal local, ejecutas el comando register. El prompt te pedirá dos datos principales. Necesita la URL de tu instancia de GitLab y el token de autenticación que acabas de generar. Este paso vincula de forma segura tu máquina local con ese proyecto específico. Finalmente, el setup te pedirá que elijas un executor. Escribes shell. A partir de ese momento, cada vez que se lance un job en ese proyecto de GitLab, tu máquina local le hará pull y ejecutará los comandos directamente en su entorno de terminal local. Aquí está la clave. GitLab es el orquestador, pero el Runner y su Executor forman la verdadera planta de producción. Al desacoplar la gestión de los jobs de la ejecución de los jobs, ganas la flexibilidad de ejecutar pipelines en cualquier cosa, desde un cloud container compartido hasta un servidor bare-metal en un sótano cerrado. ¡Gracias por escuchar, feliz programación a todos!

Hola, soy Alex de DEV STORIES DOT EU. GitLab CI/CD, episodio 3 de 14. Tienes un pipeline con veinte jobs, y cada uno empieza ejecutando exactamente el mismo comando de setup. Cuando ese proceso de setup cambia, ahora tienes veinte sitios distintos que actualizar, y con que te olvides de uno solo, se romperá tu build. Resolver esa repetición empieza por entender la anatomía de un job de CI/CD. Un job es la unidad fundamental de ejecución en GitLab CI/CD. Se define por un nombre y debe contener al menos un comando para ejecutar. Este bloque principal de ejecución se define usando la keyword script. El script representa un array de comandos que el runner ejecuta en secuencia. Si un comando falla, el job se detiene inmediatamente y se marca como fallido. Los jobs rara vez se ejecutan de forma aislada. A menudo necesitan que el entorno esté preparado antes de ejecutarse, y a veces requieren un cleanup después. Aquí es donde entran en juego las keywords before script y after script. Piensa en un proyecto de Ruby. Antes de pasar tus tests o ejecutar un linter, necesitas instalar tus dependencias. Pones tu comando bundle install dentro del bloque before script. El runner ejecuta este before script primero. Si tiene éxito, se ejecuta el script principal. Una vez que el script principal termina, se ejecuta el after script. Y aquí está la clave. El after script se ejecuta incluso si el script principal falla. Esto lo convierte en el lugar correcto para cerrar conexiones de red, borrar credenciales temporales o limpiar bases de datos de test. Escribir ese mismo comando bundle install dentro de cada job de test individual se vuelve repetitivo muy rápido. Para solucionar esto, usas la keyword default en el nivel superior de tu archivo de configuración. Cualquier configuración definida bajo default es heredada automáticamente por todos los jobs en el pipeline. Declaras tu before script de bundle install una sola vez dentro del bloque default. Ahora, cada job lo ejecuta automáticamente. Si un job específico no lo necesita, defines un before script vacío dentro de ese job en concreto. Esa definición local sobrescribe el default global. A veces necesitas una definición de job en tu archivo, pero no quieres que se ejecute realmente. Puede que estés escribiendo un template base del que heredarán otros jobs, o puede que quieras deshabilitar temporalmente un flaky test sin borrar el código por completo. Esto lo haces ocultando el job. Simplemente añade un punto justo al principio del nombre del job. Cuando GitLab parsea la configuración del pipeline, ignora por completo cualquier nombre de job que empiece por un punto. El job no aparecerá en la interfaz de usuario y no se ejecutará. A medida que tu pipeline crece, la interfaz web puede saturarse con docenas de jobs individuales. Si tienes varios jobs muy relacionados, puedes agruparlos visualmente en el gráfico del pipeline. Esto lo consigues nombrando los jobs con un prefijo compartido, seguido de un slash o dos puntos. Por ejemplo, si nombras tres jobs distintos como build slash ruby one, build slash ruby two y build slash ruby three, la interfaz los colapsará en un único grupo desplegable etiquetado simplemente como build. Al hacer clic en el grupo, este se expande para mostrar los jobs individuales de su interior. Esto no cambia nada sobre cómo se ejecutan los jobs en los runners, pero hace que un pipeline enorme sea mucho más fácil de leer de un vistazo. Un pipeline bien estructurado separa el setup de la ejecución, usa defaults para eliminar código duplicado, y se basa en convenciones de nombres para mantener la interfaz visual estrictamente enfocada en lo que importa. Eso es todo por este episodio. Gracias por escuchar, y ¡sigue programando!

Hola, soy Alex de DEV STORIES DOT EU. GitLab CI/CD, episodio 4 de 14. Hardcodear una API key directamente en la configuración de tu pipeline es la forma más rápida de comprometer todo tu entorno de producción. Necesitas una manera de pasar la configuración y las credenciales a tus jobs de forma dinámica, sin exponerlas a nadie que pueda leer tu repositorio. Las variables y los secretos de CI/CD son los mecanismos que gestionan esto. Cuando un runner de GitLab coge un job, no empieza con un estado vacío. GitLab inyecta automáticamente variables predefinidas en el entorno. Estas le dan a tu script un contexto inmediato. Tienes acceso a variables como CI commit branch, el ID del pipeline y el nombre del proyecto. No las defines tú. Simplemente están ahí, listas para usarse en tus scripts para enrutar la lógica o etiquetar los build artifacts. Además del contexto predefinido, tendrás que proporcionar tus propias variables personalizadas. Puedes definirlas en dos sitios: dentro de tu archivo de configuración yaml, o en la UI de GitLab. La regla para elegir dónde ponerlas es muy sencilla. Si el valor es seguro de leer, como un flag del compilador o la URL de un servidor de desarrollo, ponlo en el archivo yaml. La configuración se queda con el código. Si el valor es sensible, como una contraseña de base de datos, defínelo en la UI del proyecto de GitLab. Cuando pones un secreto en la UI, tienes que configurar sus límites de seguridad. La gente suele confundir enmascarar una variable con proteger una variable. Son conceptos completamente diferentes. Enmascarar una variable evita que su valor aparezca en los logs del job. Si enmascaras una contraseña de base de datos, y un script mal escrito intenta imprimirla por consola, GitLab intercepta el output stream. Reemplaza el texto real de la contraseña por un string de asteriscos antes de que el log se llegue a guardar. El enmascaramiento controla la visibilidad en los logs. Aquí está la clave. Enmascarar no hace nada para evitar que un desarrollador escriba un script que envíe la contraseña a un servidor externo. Ahí es donde entra en juego la protección. Proteger una variable limita su disponibilidad. Una variable protegida solo se inyecta en pipelines que se ejecutan en branches protegidas o tags protegidos. Si alguien abre una merge request desde una feature branch estándar, la pipeline que lance simplemente no contendrá esa variable. Esto evita que código no confiable acceda a los secretos de producción. Además, puedes usar ajustes ocultos en la UI para casos de extrema sensibilidad. Una vez que se guarda una variable, su valor se oculta en la interfaz. Ni siquiera los maintainers del proyecto pueden recuperar fácilmente el raw text más tarde, lo que significa que alguien con acceso no puede simplemente hacer scraping de la página de configuración para robar todos tus tokens. Ahora, piensa en cómo llega la variable a tu aplicación. La mayoría de las variables se inyectan como variables de entorno estándar. Pero algunas herramientas se niegan a leer variables de entorno e insisten en leer de un archivo físico. La CLI de AWS, por ejemplo, suele esperar un archivo de credenciales formateado que resida en el disco. En lugar de escribir un script de pipeline que cree un archivo, vuelque el texto de la variable en él y luego intente borrarlo de forma segura más tarde, puedes usar una variable de tipo File. Cuando configuras una variable como tipo File en la UI, el runner gestiona la logística automáticamente. Cuando empieza el job, el runner coge el valor de texto, lo escribe de forma segura en un archivo temporal en el disco del runner, y configura la variable de entorno para que contenga la ruta del archivo, no su contenido. Simplemente apuntas tu herramienta de AWS a la ruta proporcionada por la variable. Cuando el job termina, el runner destruye el archivo automáticamente. Proteger tu pipeline consiste en minimizar la exposición en cada paso. No confíes en el enmascaramiento de logs para protegerte contra código malicioso, y no escribas archivos de credenciales temporales tú mismo cuando el runner puede gestionar el ciclo de vida de forma segura. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue programando!

Hola, soy Alex de DEV STORIES DOT EU. GitLab CI/CD, episodio 5 de 14. Tu build job se completa perfectamente, pero tu deploy job falla misteriosamente con un error de archivo no encontrado. Revisas el runner, y los archivos definitivamente se generaron hace apenas unos minutos. El problema suele reducirse a un malentendido fundamental entre dos keywords: artifacts y cache. Estos dos conceptos se confunden con frecuencia porque ambos implican guardar archivos en un runner, pero existen por motivos completamente distintos. La keyword cache define una lista de archivos y directorios pensados para acelerar tu pipeline. Almacena las dependencias descargadas entre diferentes runs del pipeline. Tomemos como ejemplo un proyecto Node estándar. Tu build job requiere miles de paquetes en la carpeta node modules. En lugar de descargarlos del registry público cada vez que un desarrollador hace push de código, configuras una cache. Le asignas una key basada en tu package lock file y la apuntas al directorio node modules. En runs posteriores, GitLab restaura esos archivos localmente. Aquí está la clave. El caching es estrictamente una optimización. Si la cache se purga, expira o falla al extraerse, tu job debe poder ejecutarse y terminar con éxito descargando los paquetes desde cero. Una cache faltante solo significa un pipeline más lento, no uno roto. La lógica de tu job nunca debería depender de que haya una cache presente. Los artifacts cumplen un propósito arquitectónico completamente diferente. La keyword artifacts especifica los archivos y directorios generados por un job que deben pasarse a jobs posteriores dentro del mismo run del pipeline. No son una optimización. Son un requisito estructural para tu CI flow. Volviendo al proyecto Node, tu build job compila tu código fuente en un directorio de salida final llamado dist. Tu deploy job se ejecuta en una stage posterior y necesita esa carpeta dist exacta para hacer push a tu servidor de producción. Como los jobs se ejecutan en entornos aislados, el deploy job no puede simplemente acceder al workspace del build job. Salvas esta brecha usando artifacts. Defines la carpeta dist bajo la keyword artifacts en tu build job. Cuando el job termina con éxito, GitLab coge esos archivos, los empaqueta y los adjunta al pipeline. Cuando empieza el deploy job downstream, GitLab descarga automáticamente ese paquete de artifacts y lo extrae en el working directory. Si falta un artifact, el downstream job fallará porque los archivos necesarios literalmente no existen en el workspace. A diferencia de una cache, no puedes simplemente descargar un artifact de internet si falta. Contiene el estado intermedio y único del run actual de tu pipeline. En un archivo YAML correctamente configurado, a menudo usas ambos en el mismo build job. Configuras la cache para que apunte a tu carpeta de dependencias y así ahorrar tiempo. Configuras los artifacts para que apunten a tu carpeta de salida compilada para pasar los datos hacia adelante. El deploy job más adelante en el pipeline no necesita la cache en absoluto. Solo requiere el código compilado, que recibe sin problemas porque los artifacts se descargan por defecto en todas las stages posteriores. Cuando configures tu próximo pipeline, recuerda esta regla. Usa la cache para las dependencias externas que te descargas para ahorrar tiempo, y usa los artifacts para los resultados internos del build que debes pasar hacia adelante para completar el deploy. Eso es todo por hoy. Gracias por escuchar. Ve a construir algo genial.

Hola, soy Alex de DEV STORIES DOT EU. GitLab CI/CD, episodio 6 de 14. Acabas de hacer un commit para corregir un typo en un archivo markdown y, de repente, tu pipeline lanza una suite de tests end-to-end de veinte minutos. Eso es un desperdicio enorme tanto de minutos de computación como de tu paciencia. Para dejar de ejecutar jobs pesados cuando no son necesarios, puedes controlar la ejecución usando la keyword rules. La keyword rules determina exactamente cuándo se añade un job a un pipeline. Si llevas un tiempo usando GitLab, puede que recuerdes haber usado only y except para filtrar jobs. Esas son keywords legacy. Rules es el reemplazo moderno y más potente. Por debajo, rules recibe una lista de condiciones. GitLab evalúa esta lista de arriba a abajo. En cuanto encuentra un match, deja de buscar y añade el job o se lo salta, dependiendo de cómo hayas configurado esa regla específica. Hay tres condiciones principales que puedes evaluar. La primera es if. La condición if evalúa las variables del pipeline usando una expresión lógica simple. Puedes decirle a un job de deploy que se ejecute solo si la rama del commit coincide con la rama por defecto. Si la evaluación de la variable devuelve true, la regla hace match. Ahora, la segunda condición comprueba las modificaciones de archivos usando la keyword changes. Esto evalúa si el push actual ha modificado algún archivo que haga match con una ruta específica o un wildcard. Aquí es donde ahorras dinero de verdad. Imagina un job pesado de linter de JavaScript. No quieres que este linter se coma los ciclos de CPU si un desarrollador de backend solo ha tocado archivos de configuración de la base de datos. Añades una regla usando changes, y especificas el wildcard para los archivos punto js. Si el commit incluye cambios en un archivo javascript, la regla hace match y el linter se ejecuta. Si no se ha tocado ningún archivo javascript, el job se excluye por completo del pipeline. La tercera condición es exists. En lugar de comprobar variables o modificaciones recientes, exists simplemente comprueba si un archivo específico está presente en el repositorio en ese momento. Puede que tengas un template de pipeline genérico usado por varios proyectos. Puedes definir un job de build de contenedores con una regla exists apuntando a un Dockerfile. Si el proyecto tiene un Dockerfile en su directorio raíz, el job se ejecuta. Si no lo tiene, el job se salta por completo. Aquí está la clave. Encontrar un match no significa automáticamente que el job se ejecute. Cuando una regla se evalúa como true, aplica una instrucción secundaria usando el atributo when. Por defecto, una regla que hace match asume que el job debe añadirse al pipeline. Pero puedes definir explícitamente una regla con when configurado en never. Esto es muy efectivo para hacer blocklisting. Puedes poner una regla al principio de tu lista que diga que si el mensaje del commit contiene la palabra draft, configure when en never. Como las reglas se evalúan de arriba a abajo, ese job se cancela al instante antes de comprobar cualquier otra condición. Si hay algo que debes recordar sobre el control de la ejecución, es que el orden determina el resultado. Coloca tus reglas de exclusión en lo más alto de tu lista, porque en el momento en que GitLab encuentra una condición true, deja de leer y fija la decisión. Me gustaría tomarme un momento para darte las gracias por escucharnos, nos ayuda mucho. ¡Que tengas un buen día!

Hola, soy Alex de DEV STORIES DOT EU. GitLab CI/CD, episodio 7 de 14. Tu pipeline no es lento en realidad. Simplemente tiene un cuello de botella artificial. Probablemente tengas jobs rápidos esperando a jobs lentos que no tienen absolutamente nada que ver con ellos, simplemente porque están en la misma columna de tu pantalla. Para solucionarlo, olvídate de las columnas rígidas y crea grafos acíclicos dirigidos con needs. Por defecto, los pipelines estándar se ejecutan secuencialmente por stage. Defines stages como build, test y deploy. Cada job en el stage de test debe terminar por completo antes de que pueda empezar cualquier job en el stage de deploy. Si tu stage de test tiene cinco jobs, y cuatro de ellos terminan en dos minutos mientras que uno tarda diez minutos, todo el stage de deploy se bloquea hasta el minuto diez. La barrera de ejecución entre stages es absoluta. La palabra clave needs rompe esta barrera. Te permite definir relaciones explícitas entre jobs, pasando tu pipeline de una secuencia estricta a un grafo acíclico dirigido. Al usar la palabra clave needs en la definición de un job, le dices al sistema exactamente qué jobs anteriores deben terminar antes de que este empiece. En el momento en que esas dependencias específicas terminan con éxito, tu job se lanza. Deja de esperar a que se vacíe el resto del stage. Imagina un monorepo que contiene tanto un frontend como un backend. Los jobs de build y test del backend son rápidos, tardan unos dos minutos. Tu build del frontend es pesado, tarda diez minutos. En un pipeline tradicional, el stage de deploy no puede lanzarse hasta que terminen los tests tanto del frontend como del backend. Tu deploy del backend queda básicamente secuestrado por el build del frontend. Aquí está la clave. Puedes añadir la palabra clave needs a tu job de deploy del backend y poner solo el job de test del backend como su dependencia. Ahora, la lógica de ejecución cambia. El job de test del backend termina en el minuto dos. El job de deploy del backend ve que su dependencia explícita se ha cumplido y empieza inmediatamente. Ignora por completo el hecho de que el build del frontend seguirá ejecutándose durante otros ocho minutos. Los stages siguen existiendo para la organización visual en la interfaz de usuario, pero el orden de ejecución real ahora lo dicta el grafo que has construido. Para configurar esto, añades la palabra clave needs a un job y le pasas un array con los nombres exactos de los jobs. Hay un beneficio secundario aquí en cuanto a la transferencia de datos. Normalmente, un job descarga los artifacts de todos los jobs que han tenido éxito en los stages anteriores. Al usar needs, la descarga de artifacts se vuelve específica. Tu job solo descargará los artifacts de los jobs específicos listados en el array de needs. Esto evita que tu job de deploy del backend descargue assets del frontend masivos e irrelevantes, ahorrando aún más tiempo durante la inicialización del job. Si necesitas que un job empiece inmediatamente cuando se crea el pipeline, saltándose todos los retrasos de los stages, puedes pasarle un array vacío a la palabra clave needs. Esto le dice al sistema que el job tiene cero dependencias, forzando su ejecución en el segundo cero. El verdadero valor de un grafo acíclico dirigido es desacoplar flujos de trabajo independientes dentro de un mismo pipeline. Dejas de organizar los jobs por cuándo deberían ejecutarse, y empiezas a organizarlos puramente por los inputs que necesitan para ejecutarse. Gracias por escuchar. Cuidaos todos.

Hola, soy Alex de DEV STORIES DOT EU. GitLab CI/CD, episodio 8 de 14. Mantienes un proyecto open-source. Un desconocido le hace un fork, oculta un script que exporta variables de entorno dentro de un unit test, y abre una contribución. Si tu sistema ejecuta automáticamente ese código en tus servidores privados, tus secretos se perderán. Para evitar esto, necesitas una separación estricta entre simplemente hacer push de código y ejecutarlo en un entorno privilegiado. Esa separación se gestiona mediante las Merge Request Pipelines. Normalmente, GitLab lanza una pipeline cada vez que haces push de un commit a cualquier branch. Una merge request pipeline se comporta de manera diferente. Es un tipo específico de pipeline configurada para ejecutarse en el contenido de la source branch, pero solo dentro del contexto de una merge request abierta. Este contexto te da acceso a variables de entorno específicas relacionadas con el propio merge, como el nombre de la target branch o el identificador de la merge request. Le indicas a un job que se ejecute como una merge request pipeline usando la sección rules en tu archivo de configuración. Escribes una regla que evalúa la variable pipeline source. Compruebas si la CI pipeline source es igual al texto exacto merge request event, escrito con guiones bajos entre las palabras. Al aplicar esta regla, el job solo se ejecutará cuando se cree o actualice una merge request. Es muy común combinar esto con reglas que impiden que el job se ejecute en los pushes estándar a la branch. Si no los separas, hacer push de un commit a una merge request abierta lanzará dos pipelines exactamente al mismo tiempo haciendo exactamente el mismo trabajo. Esto nos lleva a las implicaciones de seguridad de las contribuciones externas. Cuando alguien hace un fork de tu repositorio, crea una copia completamente aislada. Si abre una merge request desde su fork hacia tu proyecto principal, cualquier pipeline que se ejecute automáticamente lo hará dentro de su fork. Utiliza sus runners y sus variables. Esto es así por diseño. Los secretos de tu proyecto principal están a salvo porque el código del colaborador no tiene acceso a tu infraestructura. Pero, al final, necesitas verificar que su código pasa tu test suite oficial usando tus propias credenciales de base de datos y targets de deploy. GitLab te permite ejecutar pipelines para estas merge requests de forks dentro del proyecto principal, pero requiere una acción humana deliberada. Un desarrollador o maintainer del proyecto principal debe lanzar manualmente la ejecución. En un workflow adecuado, el maintainer lee primero el código enviado desde el fork. Debe buscar cualquier cosa maliciosa, destructiva o mal construida. Solo cuando el maintainer está completamente seguro de que el código es seguro, hace clic en el botón para lanzar la pipeline. Una vez lanzada, ese código externo se ejecuta en los runners del proyecto principal y tiene acceso a los secretos del proyecto principal. El trigger manual actúa como una barrera de seguridad física. Esta es la parte que importa. Las merge request pipelines no son solo una forma de agrupar jobs en la interfaz de usuario, son un mecanismo de control fundamental que te permite evaluar código externo sin exponer ciegamente tu infraestructura interna. Si quieres ayudar a mantener esto en marcha, puedes apoyar el programa buscando DevStoriesEU en Patreon. Eso es todo por este episodio. ¡Gracias por escuchar, y a seguir programando!

Hola, soy Alex de DEV STORIES DOT EU. GitLab CI/CD, episodio 9 de 14. Tienes un único archivo YAML con quinientos jobs. Cambiar una sola línea es como desactivar una bomba, y la ejecución tarda una hora porque todo corre en un único bloque masivo. Las downstream pipelines solucionan esto dividiendo ese monolito en workflows modulares e independientes. Una downstream pipeline es simplemente cualquier pipeline de GitLab CI/CD que es activada por otra pipeline. La pipeline que la activa se llama upstream pipeline. En lugar de ejecutar cada job en una sola secuencia, la upstream pipeline actúa como coordinadora, delegando el trabajo a pipelines más pequeñas y específicas. GitLab divide las downstream pipelines en dos tipos específicos según dónde se ejecutan. El primer tipo es una pipeline parent-child. Esto ocurre completamente dentro del mismo proyecto. Si tienes un monorepo, un setup parent-child es justo lo que necesitas. La parent pipeline detecta qué ha cambiado y activa solo la configuración child relevante. El segundo tipo es una multi-project pipeline. Esto ocurre cuando una pipeline en un repositorio activa una pipeline en un proyecto de GitLab completamente diferente. Esto lo usas para arquitecturas distribuidas en varios repositorios, como activar un proyecto de integration testing solo después de que la pipeline de un proyecto de API independiente termine con éxito. Ambos tipos los configuras usando una keyword de job específica llamada trigger. Un trigger job es fundamentalmente diferente de un job estándar. Nunca contiene una sección script. No ejecuta comandos en un runner. Su único propósito es iniciar la downstream pipeline. Para una multi-project pipeline, le pasas a la keyword trigger la ruta al proyecto de destino. Para una pipeline parent-child, usas la keyword trigger combinada con la keyword include, apuntando a un archivo YAML diferente ubicado en el mismo repositorio. Imagina una parent pipeline de enrutamiento que gestiona tres microservicios independientes almacenados en un monorepo. La parent pipeline evalúa el commit y activa tres child pipelines en paralelo. Una gestiona el servicio de usuarios, otra el servicio de pagos y otra el servicio de inventario. Cada child pipeline tiene sus propios stages, jobs y rules. Se ejecutan de forma independiente. Por defecto, un trigger job se lanza y se olvida. El upstream job inicia la downstream pipeline y termina con éxito de inmediato. Si necesitas que la upstream pipeline espere y refleje el estado de la downstream pipeline, añades el parámetro strategy depend al trigger job. Esto obliga a la parent pipeline a esperar, lo que significa que un fallo en la child pipeline subirá y marcará el parent job como fallido. Aquí está la clave. Los ingenieros suelen configurar pipelines parent-child y asumen inmediatamente que están rotas porque las child pipelines no aparecen en la página principal del index de pipelines. Esta es una decisión de diseño intencionada. El index principal solo muestra las parent pipelines para evitar el desorden. Para ver las child pipelines, tienes que hacer clic en la vista de detalle de la parent pipeline. Están anidadas bajo el job específico que las activó. Las multi-project pipelines, por otro lado, sí aparecen en el index de pipelines de sus respectivos proyectos de destino, porque son top-level pipelines en esos repositorios. Pasar a downstream pipelines te obliga a tratar tu configuración de CI/CD como una arquitectura de software real, reemplazando un script frágil por componentes distintos que tienen dominios de fallo aislados. Eso es todo por este episodio. ¡Hasta la próxima!

Hola, soy Alex de DEV STORIES DOT EU. GitLab CI/CD, episodio 10 de 14. Si tu equipo depende de preguntar en Slack para saber quién acaba de hacer push al servidor de staging, tienes una brecha de visibilidad en tu flujo de trabajo. Necesitas una forma definitiva y automatizada de rastrear con precisión qué código se está ejecutando y dónde en cada momento, y ese es precisamente el problema que resuelven los Environments y Deployments de GitLab. En GitLab, un environment es una entidad lógica de seguimiento. GitLab no aprovisiona automáticamente tus servidores ni levanta tu infraestructura en la nube solo porque hayas creado un environment. El environment es simplemente una etiqueta. Le indica a GitLab que un job específico en tu pipeline es responsable de hacer push de código a un destino específico, como staging o producción. Puedes configurarlo añadiendo la palabra clave environment directamente en tu job de deploy. Proporcionas un nombre estático para el destino. Por ejemplo, puedes crear un job llamado deploy to staging y, dentro de ese job, establecer el nombre del environment como staging. La sección de script de tu job sigue gestionando el trabajo real. Ejecuta los comandos que copian archivos, aplican configuraciones o reinician servicios remotos. Imagina el escenario en el que estás haciendo deploy de una nueva release candidate. Haces merge de tu código y se inicia el pipeline. Compila la aplicación, ejecuta tu suite de tests y llega al job de deploy a staging. Como has añadido la palabra clave environment a este job, GitLab cambia cómo trata la ejecución. Monitoriza de cerca la salida del job. Cuando tu script de deploy finaliza y el job termina correctamente, GitLab registra un evento de deploy formal para el environment de staging. Aquí está la clave. Usar esa única palabra clave activa todo un conjunto de funciones de seguimiento de deploys en la interfaz de GitLab. Si navegas al menú Operate en la barra lateral y seleccionas Environments, verás un dashboard que muestra el estado en tiempo real de tus destinos de deploy. Para tu environment de staging, ya no tienes que adivinar qué se está ejecutando. El dashboard muestra el commit hash exacto que está activo, la branch de la que proviene ese commit, el autor del código y cuánto tiempo hace que finalizó el deploy. Crea un registro compartido e inmutable del estado del servidor. Todos en el proyecto tienen exactamente la misma visibilidad sin necesidad de consultar los logs del servidor ni preguntar a los compañeros. Al hacer clic en el environment de staging, se revela el historial completo de deploys. Este registro histórico es lo que permite hacer rollbacks manuales directamente desde la interfaz de usuario. Si una nueva release candidate rompe por completo el servidor de staging, solucionarlo no requiere escribir un revert commit ni construir manualmente un pipeline anterior. Abres la lista del historial, identificas el último deploy exitoso conocido y haces clic en el botón de rollback que hay al lado. GitLab vuelve a ejecutar inmediatamente el job de deploy desde ese commit anterior y estable. Reemplaza el código roto y restaura rápidamente tu environment de staging a un estado funcional. Al usar la palabra clave environment, cierras la brecha entre la ejecución de scripts y el seguimiento de los deploys reales. Convierte un job de pipeline aislado en un registro claro y visible de la versión de software que vive actualmente en tu infraestructura. Me gustaría tomarme un momento para agradecerte que nos escuches; nos ayuda mucho. ¡Que tengas un buen día!

Hola, soy Alex de DEV STORIES DOT EU. GitLab CI/CD, episodio 11 de 14. Entregarle a tu product manager una URL en vivo y clicable para cada feature branch elimina por completo el argumento de que funciona en tu máquina. Este workflow se basa totalmente en entornos dinámicos y Review Apps. Los entornos estándar, como staging o producción, son estáticos. Los defines una vez y persisten. Los entornos dinámicos se crean sobre la marcha. Los levantas para probar una branch específica, los usas y luego los descartas. Cuando usas un entorno dinámico específicamente para previsualizar cambios de código dentro de una merge request, GitLab lo llama Review App. Para crear un entorno dinámico, no puedes hardcodear su nombre en tu archivo de configuración. En su lugar, usas variables de pipeline. La variable más crítica para esto es el CI commit ref slug. Esta variable toma el nombre de tu branch, lo convierte a minúsculas, elimina los caracteres especiales y lo acorta. Te garantiza tener un string seguro para DNS que puedes usar para nombrar tanto tu entorno en GitLab como tus recursos de infraestructura reales. Al definir el nombre de tu entorno como la palabra review seguida de una barra y esta variable slug, GitLab genera automáticamente un entorno independiente y trackeado para cada branch a la que hagas push. Aquí está la clave. Crear el registro del entorno en GitLab es solo la mitad de la batalla. También necesitas dirigir a los revisores al código desplegado. Supongamos que estás levantando una instancia temporal de AWS Lambda para tu feature branch. Cuando se ejecuta tu script de deploy, AWS genera una URL aleatoria para esa nueva función Lambda. No conoces esta URL de antemano. Necesitas una forma de pasar esa dirección generada dinámicamente de vuelta a la interfaz de usuario de GitLab para que los revisores puedan hacer clic en ella. Esto lo solucionas usando un tipo de artifact específico llamado dotenv report. Dentro de tu job de deploy, después de que AWS aprovisiona la función Lambda y devuelve el endpoint, tu script escribe esa URL en un archivo de texto simple formateado como un par clave-valor. Configuras tu job para que devuelva este archivo como un artifact de tipo dotenv report. GitLab lee este archivo al final del job y expone la variable. Luego, configuras el parámetro environment URL en la definición de tu pipeline para que lea exactamente esa variable. Gracias a esta conexión, tu merge request mostrará ahora un botón View App que redirige a los usuarios directamente a ese endpoint específico de AWS Lambda. La infraestructura temporal cuesta dinero. Dejar cientos de funciones Lambda obsoletas en ejecución agotará rápidamente tu presupuesto. Necesitas una forma automatizada de hacer limpieza. Esto lo gestionas usando la palabra clave on stop. En tu job de deploy, agregas la propiedad on stop y le asignas el nombre exacto de un job diferente en tu pipeline. Este segundo job contiene tu script de teardown de infraestructura. Al vincularlos de esta manera, GitLab se encarga de la gestión del ciclo de vida. Cuando un desarrollador hace merge de la feature branch, o borra la branch, GitLab ejecuta automáticamente ese job de teardown. La infraestructura se destruye inmediatamente. El verdadero valor de las Review Apps no es solo previsualizar código, sino automatizar todo el ciclo de vida de la infraestructura. Aprovisionas dinámicamente, vinculas sin problemas y destruyes de forma fiable entornos temporales sin que un solo desarrollador tenga que tocar jamás una consola de hosting. Eso es todo por este episodio. Gracias por escuchar, y ¡sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. GitLab CI/CD, episodio 12 de 14. Copiar y pegar el mismo script de deploy en cincuenta repositorios diferentes garantiza una cosa: cuando ese script inevitablemente tenga que cambiar, olvidarás actualizar al menos un repositorio. La solución es escribir configuraciones DRY usando la keyword include. En GitLab CI, la keyword include te permite dividir la configuración de tu pipeline en varios archivos más pequeños y reutilizables. En lugar de mantener un archivo YAML enorme, creas un sistema modular. Cuando un pipeline hace trigger, GitLab se pausa, hace fetch de todos los archivos incluidos, hace un merge con ellos y luego evalúa la configuración combinada como un todo. Hay tres subkeys principales que usas para traerte estos archivos externos. La más sencilla es local. Usas include local para traerte un archivo que vive exactamente en el mismo repositorio que tu archivo principal del pipeline. Esto es estrictamente para organizar un solo proyecto grande. Puedes separar toda tu lógica de testing en un archivo llamado test pipeline punto yml, poner tu lógica de deploy en deploy pipeline punto yml, y mantener limpio tu archivo de configuración root simplemente referenciando esos paths locales. La segunda subkey es project, y aquí es donde la modularidad del pipeline escala a toda la organización. Include project hace pull de un archivo YAML desde un repositorio completamente diferente alojado en la misma instancia de GitLab. Especificas el path del proyecto externo, junto con el path del archivo y, opcionalmente, la branch o referencia de commit específica de la que quieres hacer pull. Imagina un equipo de plataforma que mantiene un pipeline central de escaneo de seguridad. En lugar de tener a cincuenta equipos de microservicios diferentes escribiendo y manteniendo sus propios jobs de seguridad, el equipo de plataforma mantiene una única template YAML de referencia en un proyecto de plataforma dedicado. Los cincuenta proyectos de microservicios simplemente añaden un bloque include project apuntando a ese repositorio central. Cuando el equipo de plataforma actualiza la versión del escáner o ajusta las reglas de seguridad en su template, los cincuenta microservicios ejecutan automáticamente las comprobaciones actualizadas en su próxima ejecución del pipeline. No hace falta copiar y pegar repetidamente. La tercera subkey es remote. Include remote toma una URL HTTPS completa y hace fetch de un archivo de configuración desde cualquier servidor web público. Puedes usar esto para hacer pull de definiciones de pipeline proporcionadas por un proveedor o estándares open source de la comunidad. El único requisito estricto es que la URL debe ser accesible públicamente mediante una request web estándar sin autenticación. Ahora, presta atención a esta parte. A menudo te encontrarás con una situación en la que un archivo incluido define un job, pero el proyecto local necesita modificarlo ligeramente. GitLab gestiona esto mediante su comportamiento de merge. Cuando se incluyen archivos, GitLab hace un deep merge de las configuraciones. Si un archivo incluido define un job llamado run security scan, y tu archivo principal también define un job llamado run security scan, la configuración de tu archivo principal tiene prioridad. Esto significa que no tienes que descartar una template centralizada solo porque tu proyecto específico necesite un pequeño ajuste. Puedes incluir la template del equipo de plataforma, y luego definir localmente solo el job run security scan con una variable actualizada o añadiendo un script personalizado. Tus overrides locales se aplican, mientras que el resto de la definición del job permanece exactamente como la escribió el equipo de plataforma. El verdadero poder de la modularidad de pipelines no reside solo en centralizar el código, sino en diseñar templates como valores por defecto sensatos a los que los proyectos downstream pueden hacer override localmente sin romper la cadena de herencia. Eso es todo por este episodio. Gracias por escuchar, y ¡sigue programando!

Hola, soy Alex de DEV STORIES DOT EU. GitLab CI/CD, episodio 13 de 14. Tu pipeline acaba de fallar porque alguien actualizó un snippet YAML compartido a tres repositorios de distancia. No recibiste ningún aviso, y ahora estás perdiendo una hora arreglando un job que ni siquiera escribiste. Se acabaron los días de depender de snippets YAML frágiles y sin versionar. Los componentes de CI/CD y el CI/CD Catalog solucionan esto llevando la fiabilidad de un package manager directamente a tus pipelines. Los componentes son configuraciones de pipeline reutilizables y de un solo propósito. Son la evolución moderna del antiguo método include template. Con las templates antiguas, básicamente importabas YAML en crudo a través de la red. Si el archivo upstream cambiaba, tu pipeline cambiaba al instante, a menudo con resultados desastrosos. Los componentes solucionan esto forzando un versionado estricto. El CI/CD Catalog funciona como el registry centralizado donde tu organización puede publicar, descubrir y compartir estos componentes versionados. Para crear un componente, necesitas un repositorio con una estructura de archivos muy específica. La lógica principal debe vivir dentro de un directorio llamado explícitamente templates. Dentro de este directorio, puedes colocar varios archivos YAML, donde cada archivo representa un componente distinto. En la raíz del repositorio, también debes incluir un archivo readme punto md. Este archivo markdown no es solo una sugerencia amable. Actúa como la documentación oficial que se muestra en el Catalog, detallando qué hace el componente y qué parámetros requiere. Aquí está la clave. Los componentes son demasiado rígidos para ser útiles sin inputs. Los inputs funcionan exactamente igual que los argumentos de una función para la configuración de tu pipeline. Cuando escribes el YAML del componente, declaras un bloque en la parte superior que define los inputs aceptados. Especificas sus nombres, sus valores por defecto y si son obligatorios. Imagina un equipo de platform engineering que está implementando escaneos de seguridad obligatorios. Crean un proyecto de componente llamado corporate-security. Dentro del directorio templates, escriben un archivo específicamente para la detección de secretos. Para mantenerlo flexible, definen un único input obligatorio llamado stage. Los desarrolladores de aplicaciones de toda la empresa ya no necesitan escribir ni mantener los jobs de detección de secretos ellos mismos. Para consumir ese mismo componente de detección de secretos, un desarrollador usa la sintaxis include component en la configuración de su pipeline. Especifica la ruta al componente en el servidor. Luego, añade una arroba seguida de una versión semántica, como uno punto cero punto cero. Este es el paso crucial. Fijar la versión semántica garantiza que el pipeline nunca se romperá inesperadamente, incluso si el equipo de plataforma lanza una versión dos punto cero punto cero muy modificada más adelante esa misma semana. Si un desarrollador quiere intencionadamente lo más nuevo, puede añadir la etiqueta especial tilde latest en lugar de un número de versión, pero el semantic versioning es la opción por defecto más segura. Justo debajo de la declaración include, el desarrollador pasa sus variables, mapeando el input stage a la etapa del pipeline que mejor encaje con su proyecto específico, como test o pre-build. Tratar la lógica del pipeline como software versionado cambia la forma en que los equipos escalan la infraestructura. El verdadero poder de los componentes no es solo la reutilización de código, es la garantía absoluta de que un pipeline que se ejecuta con éxito hoy, se ejecutará exactamente de la misma manera dentro de seis meses. Gracias por escuchar. Cuidaos todos.

Hola, soy Alex de DEV STORIES DOT EU. GitLab CI/CD, episodio 14 de 14. Intentas definir el nombre del stage de un job usando una variable de CI estándar, haces push de tu código e inmediatamente recibes un error de sintaxis. El pipeline se niega a ejecutarse. El problema es el timing. El runner no puede definir la estructura del pipeline usando variables que solo recibe después de que el pipeline ya ha comenzado. Aquí es precisamente donde entran en juego las expresiones de CI en tiempo de compilación. La clave está en lo siguiente. Las variables estándar de runtime, escritas con un solo signo de dólar, son evaluadas por la shell cuando el job realmente se ejecuta. Para cuando el runner las ve, toda la arquitectura del pipeline ya está bloqueada. No puedes cambiar dinámicamente el nombre de un stage, un service o la versión de una imagen durante la ejecución porque GitLab necesita esa información de antemano para construir el grafo del pipeline. Las expresiones en tiempo de compilación solucionan esto evaluando la lógica en el momento exacto en que GitLab parsea tu configuración YAML, mucho antes de que se asigne ningún runner. La sintaxis utiliza un signo de dólar seguido de corchetes dobles. Dentro de esos corchetes, escribes una expresión que se evalúa a un valor antes de que se cree el pipeline. Estas expresiones obtienen sus datos de contextos específicos. Un contexto es, esencialmente, un conjunto restringido de datos disponibles durante el parseo del YAML. El contexto más importante es el contexto de inputs, que se utiliza muchísimo al crear componentes de CI/CD. Imagina el escenario de un componente de deploy dinámico. Quieres que el proyecto que consume este componente pase un nombre de entorno como input. Luego, quieres usar ese input para establecer el nombre del stage del job y dictar la versión específica de la imagen de Docker a la que le hace pull. Dentro de la configuración de tu componente, escribes el campo stage y le asignas una expresión en tiempo de compilación que contiene inputs punto environment. Cuando un proyecto incluye tu componente, GitLab lee el input de environment proporcionado. Evalúa la expresión inmediatamente. El grafo del pipeline resultante ve un nombre de stage estático y hardcodeado, y un tag de imagen hardcodeado. El runner nunca se encuentra con los corchetes dobles. Simplemente recibe la configuración estándar. Más allá de los inputs, las expresiones en tiempo de compilación también soportan un contexto matrix, que actualmente está en fase beta. Cuando generas jobs paralelos usando una keyword como parallel matrix, puedes usar expresiones en tiempo de compilación para ajustar dinámicamente las propiedades del job basándote en las variables específicas asignadas a cada instancia paralela. Esto evita que tengas que duplicar las definiciones de los jobs solo para cambiar uno o dos campos por cada ejecución de la matrix. Estas expresiones son más potentes que la simple sustitución de texto. Puedes escribir lógica directamente dentro de los corchetes usando operadores de igualdad, así como operadores lógicos AND y OR. Puedes evaluar si un input coincide con un string específico, y cambiar un valor condicionalmente según el resultado. También tienes acceso a funciones built-in. La función expand vars, por ejemplo, te permite inyectar de forma segura valores de tiempo de compilación en un string, conservando explícitamente la sintaxis estándar de las variables de runtime. Esto garantiza que el runner siga recibiendo las variables de runtime que espera sin causar conflictos de parseo desde el principio. La conclusión principal es que las expresiones en tiempo de compilación te dan un mecanismo nativo para crear plantillas de tu grafo del pipeline, separando claramente la lógica de generación estructural de la ejecución real del script. Dedica un tiempo a leer la documentación oficial de GitLab, revisar las funciones soportadas e intentar hacer deploy de un componente de forma práctica. Si tienes temas que te gustaría que abordáramos en una futura serie, visita devstories dot eu y cuéntanoslo. Gracias por dedicarme unos minutos. Hasta la próxima, ¡que te vaya bien!