Cómo crear un pipeline CI/CD con GitLab

Un runner es la aplicación, escrita en Go y distribuida como un solo binario, que se conecta a GitLab, toma los jobs pendientes de la cola y ejecuta el script de cada uno dentro de un ejecutor concreto: shell, Docker, Docker con autoescalado o SSH. Sin un runner disponible, ningún job se ejecuta, por más completo que esté el .gitlab-ci.yml: el YAML describe qué hacer, pero el runner es quien lo hace. No hace falta instalar uno propio para empezar: GitLab.com ofrece runners compartidos, ya alojados, listos apenas creás el proyecto, y el plan gratuito incluye minutos mensuales para usarlos. Un runner propio, o self-hosted, se justifica cuando hace falta hardware específico como una GPU, acceso a una red privada, evitar el límite de minutos, o dependencias particulares preinstaladas. Se instala descargando el binario o corriéndolo en un contenedor, y se registra contra el proyecto con un token. Para proyectos chicos o medianos, los compartidos suelen alcanzar sin configuración adicional.

Un stage, o etapa, es una fase del pipeline, como build, test o deploy, y las etapas corren en secuencia, en el orden en que aparecen en la clave stages: primero termina build, después arranca test, y recién después deploy. Un job, o trabajo, es una tarea concreta dentro de una etapa, con su propio script, y todos los jobs de una misma etapa corren en paralelo, no en secuencia. Si test tiene dos jobs, unit-tests y lint, ambos arrancan apenas termina build, sin esperarse entre ellos, y deploy recién arranca cuando los dos terminaron. Esta combinación hace eficiente un pipeline: las etapas imponen el orden que el proceso necesita —no desplegar código sin probar—, y el paralelismo dentro de cada etapa aprovecha que tareas independientes no tienen por qué esperarse. Un error común es creer que el orden lo da la posición en el archivo: lo determina el stage de cada job. Y si un job falla, la etapa siguiente no arranca: el pipeline se detiene ahí.

El orden de stages es estricto: por defecto, ningún job de deploy arranca hasta que todos los jobs de test terminaron, aunque ese job en particular no dependa de todos ellos. La clave needs rompe esa espera innecesaria: le permite a un job declarar de qué jobs concretos depende, sin importar la etapa, y arrancar en cuanto esas dependencias puntuales terminan, en vez de esperar a que termine la etapa entera. Un caso típico: un job de deploy que solo necesita el artefacto de build, sin depender de test; con needs: [build], arranca apenas build termina, en paralelo con test. El resultado es un pipeline más rápido, porque corren en paralelo tareas sin dependencia real entre sí aunque estén en etapas distintas. Conviene usarlo con cuidado: un pipeline con muchos needs cruzados puede volverse difícil de seguir, porque el orden real ya no coincide con el de las etapas. Reservalo para casos donde el ahorro sea claro.

Las credenciales que el pipeline necesita para desplegar —una clave de servidor, un token, una contraseña— se cargan en la sección de variables de CI/CD del proyecto, nunca escritas dentro de .gitlab-ci.yml, porque ese archivo se versiona y queda visible para quien tenga acceso al repositorio. Cada variable se puede marcar como protegida, disponible solo en pipelines de ramas o etiquetas protegidas como main, y como enmascarada, oculta con asteriscos en los registros. Es clave entender los límites reales: GitLab advierte explícitamente que el enmascarado no es una garantía total de seguridad, porque un script que transforme o concatene el valor antes de imprimirlo puede terminar exponiéndolo en el log igual. Enmascarar no es cifrar: reduce la exposición accidental, no protege criptográficamente. Por eso conviene además separar entornos con variables distintas para pruebas y producción, y limitar quién puede editar la configuración de CI/CD.

Es una de las confusiones más comunes al empezar con GitLab CI/CD, porque ambos guardan archivos entre ejecuciones, pero resuelven problemas distintos. Los artifacts son archivos que produce un job —el resultado de una compilación, un reporte de pruebas— y que sobreviven después de que el job termina: quedan asociados a esa ejecución, se pueden descargar desde la interfaz, y sobre todo se pasan automáticamente a los jobs posteriores del mismo pipeline, con una caducidad configurable vía expire_in. La cache, en cambio, no pasa el resultado de un job a otro dentro del mismo pipeline: acelera ejecuciones futuras reutilizando algo que no cambia seguido, como una carpeta node_modules. La diferencia clave: la cache se comparte entre pipelines distintos, no solo entre jobs de una misma corrida; si dos ejecuciones usan la misma clave de cache, la segunda reaprovecha lo que la primera descargó. En resumen, artifacts pasa el resultado de este pipeline a un job posterior, y cache evita repetir un trabajo costoso en cada pipeline nuevo.

Según la página oficial de precios de GitLab, consultada el 29 de julio de 2026, el plan gratuito incluye 400 minutos de cómputo por mes en los runners compartidos de GitLab.com, junto con 10 GiB de almacenamiento. Ese límite aplica al uso de runners compartidos: con uno propio, autogestionado, no aplica, porque el cómputo lo pone tu hardware. Por encima del plan gratuito hay niveles pagos, como Premium, y un nivel Ultimate para organizaciones grandes. Estas cifras son datos comerciales que GitLab actualiza seguido, así que conviene confirmarlas en la página de precios vigente antes de planificar un proyecto alrededor de un número puntual. Para un proyecto chico con pipelines livianos, los minutos gratuitos suelen alcanzar; con pipelines largos o mucha gente contribuyendo, es habitual toparse con el límite y evaluar un plan pago o un runner propio.