--- title: CI/CD: Conceptos básicos — pipeline, job, stage, step y gates url: https://jarroba.com/ci-cd-conceptos-basicos-pipeline-job-stage-step-y-gates/ author: Ramón Invarato date: 2026-04-19 modified: 2026-10-21 language: es license: CC BY-NC-SA 3.0 (https://creativecommons.org/licenses/by-nc-sa/3.0/) — attribution: "CI/CD: Conceptos básicos — pipeline, job, stage, step y gates", Ramón Invarato, jarroba.com categories: Ingeniería del Software, Inteligencia Artificial tags: ci-cd, devops, github-actions, gitlab-ci, jenkins, pipeline series: CI/CD y la IA: De la teoría a la práctica (part 2 of 11) --- # CI/CD: Conceptos básicos — pipeline, job, stage, step y gates > Los bloques básicos de cualquier pipeline de CI/CD: pipeline, gates, jobs, stages y steps, y cómo se llaman en GitHub Actions, GitLab CI y Jenkins. > Antes de diseñar o trabajar con un pipeline de CI/CD (integración y entrega continua), hay que dominar su vocabulario. Este artículo define los conceptos fundamentales y los relaciona con las tres herramientas más extendidas: [GitHub Actions](https://github.com/features/actions), [GitLab CI](https://docs.gitlab.com/ci/) y [Jenkins](https://www.jenkins.io/). ## Pipeline Un **pipeline** es un conjunto de stages (etapas) que se ejecutan en secuencia para construir, probar, desplegar y mantener un producto software. [![](https://jarroba.com/wp-content/uploads/2026/04/1-CI-CD-Conceptos-basicos-pipeline-job-stage-step-y-gates-Pipeline-www.jarroba.com_-432x1024.png)](https://jarroba.com/wp-content/uploads/2026/04/1-CI-CD-Conceptos-basicos-pipeline-job-stage-step-y-gates-Pipeline-www.jarroba.com_.png) ## Gates (puertas de calidad) Un **gate** (puerta de calidad) es un punto de control obligatorio dentro de un pipeline donde se evalúan criterios de calidad, seguridad o cumplimiento antes de permitir que el flujo continúe. - Si el gate **se cumple** → el pipeline avanza a la siguiente stage. - Si el gate **no se cumple** → el pipeline se detiene y el error se devuelve al desarrollador para que lo corrija. [![](https://jarroba.com/wp-content/uploads/2026/04/2-CI-CD-Conceptos-basicos-pipeline-job-stage-step-y-gates-Comprobacion-de-un-gate-www.jarroba.com_-1024x308.png)](https://jarroba.com/wp-content/uploads/2026/04/2-CI-CD-Conceptos-basicos-pipeline-job-stage-step-y-gates-Comprobacion-de-un-gate-www.jarroba.com_.png) El gate más conocido quizás sea el **gate de [SonarQube](https://www.sonarsource.com/products/sonarqube/)** (lo he visto en casi todas las empresas o, si no, una variante que hace algo semejante): es un gate de calidad de código que evalúa la calidad del código fuente y detecta posibles problemas de seguridad y vulnerabilidades. Aunque el “gate” formal reside dentro del pipeline, en local hay unos **“gates locales y mentales”** que un desarrollador pasa antes de hacer commit (antes de subir el código al repositorio): - El proyecto se **compila** y se **ejecuta** en local. - **Lint** (herramienta que verifica el estilo y la sintaxis del código) sin errores. - **Formato** consistente. - **Tests unitarios y de integración** ejecutados en local con todo en verde. ## Job (tarea) El **Job** es una unidad ejecutable dentro de un pipeline y se agrupa en stages. Algunos ejemplos de jobs típicos son: - Compilar (build) el proyecto. - Empaquetar el proyecto en un formato que pueda ser desplegado (imagen de [Docker](https://www.docker.com/), JAR, WAR, etc.). - Ejecutar tests (como los unitarios o de integración). ## Stage (fase) y Step (paso) Estos conceptos son muy similares (en GitHub Actions incluso uno no existe como palabra clave propia). Sirven para agrupar jobs. La diferencia: - **Stage**: es una fase completa del pipeline (es decir, una función lógica). - **Step**: es una acción individual dentro de esa stage. Es decir: un pipeline tiene stages → un stage tiene steps → un step tiene jobs. [![](https://jarroba.com/wp-content/uploads/2026/04/3-CI-CD-Conceptos-basicos-pipeline-job-stage-step-y-gates-Jerarquia-pipeline-stage-step-job-www.jarroba.com_-466x1024.png)](https://jarroba.com/wp-content/uploads/2026/04/3-CI-CD-Conceptos-basicos-pipeline-job-stage-step-y-gates-Jerarquia-pipeline-stage-step-job-www.jarroba.com_.png) ## Tabla de equivalencias entre GitHub Actions, GitLab CI y Jenkins La nomenclatura varía entre herramientas, pero los conceptos son equivalentes: | Concepto | [GitHub Actions](https://github.com/features/actions) | [GitLab CI](https://docs.gitlab.com/ci/) | [Jenkins](https://www.jenkins.io/) | Equivalencia conceptual | | --- | --- | --- | --- | --- | | **Pipeline (Flujo de CI/CD)** | Workflow | Pipeline | Pipeline | El flujo completo de CI/CD | | **Stage (Fase)** | *No existe como palabra clave* (se simula con jobs y `needs`) | Stage | Stage | Agrupación lógica de pasos | | **Job (Tarea)** | Job | Job | Stage (con steps) | Unidad ejecutable con su propio agente | | **Step (Paso)** | Step | Script (líneas dentro del job) | Step | Acción individual dentro de un job | | **Runner / Executor (Ejecutor)** | Runner | Runner | Agent | Máquina donde se ejecuta | | **Gate / Approval** | Environment protection rules | `when: manual` | `input` | Punto de aprobación o control | | **Artifact (Artefacto)** | `actions/upload-artifact` | `artifacts:` | `archiveArtifacts` | Archivos que pasan entre stages | | **Dependency (Dependencia)** | `needs:` | `needs:` | `post` / orden de stages | Control de orden y dependencias | ## Ejemplos con código ### Pipeline con gate de aprobación manual **Jenkins** (se guarda en un archivo `Jenkinsfile`; [documentación de Jenkinsfile aquí](https://www.jenkins.io/doc/book/pipeline/jenkinsfile/) ): ```groovy pipeline { agent any stages { stage('Build') { steps { echo 'Building...' } } stage('Approval Gate') { steps { script { input message: '¿Aprobar despliegue?' } } } stage('Deploy') { steps { echo 'Deploying...' } } } } ``` **GitHub Actions** (se guarda en `.github/workflows/hello.yml`; [documentación de GitHub Actions aquí](https://docs.github.com/es/actions) ): ```yaml name: Pipeline con Gate on: workflow_dispatch: jobs: build: runs-on: ubuntu-latest steps: - run: echo "Building..." deploy: runs-on: ubuntu-latest needs: build environment: production # ← Aquí GitHub pedirá aprobación si el environment tiene reglas steps: - run: echo "Deploying to production..." ``` **GitLab CI** (se guarda en `.gitlab-ci.yml`; [documentación de GitLab CI aquí](https://docs.gitlab.com/ci/yaml/) ): ```yaml stages: - build - deploy build: stage: build script: - echo "Building..." deploy: stage: deploy script: - echo "Deploying..." when: manual # ← Gate manual allow_failure: false ``` ## Las herramientas principales Aunque los conceptos de pipeline, stage, job y gate son universales, cada herramienta tiene su propia sintaxis y su fichero de configuración característico. Estas son las tres más extendidas hoy: ### GitHub Actions Servicio de CI/CD gestionado por GitHub (Microsoft). No requiere infraestructura propia — los pipelines se ejecutan en runners de GitHub o en runners autoalojados. - **Fichero de configuración:** `.github/workflows/.yml` (dentro del repositorio) - **Disparadores:** push, pull request, schedule, workflow_dispatch, etc. - **Cuándo usarlo:** proyectos en GitHub, startups, open source, equipos que quieren velocidad sin gestionar servidores. **Esqueleto mínimo:** ```yaml name: Mi pipeline on: push: branches: [main] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Compilar run: echo "compilando..." test: runs-on: ubuntu-latest needs: build # depende de build steps: - name: Tests run: echo "tests..." deploy: runs-on: ubuntu-latest needs: test environment: production # ← gate de aprobación si el environment tiene reglas steps: - name: Deploy run: echo "desplegando..." ``` ### GitLab CI CI/CD integrado en GitLab. Disponible tanto en la nube (gitlab.com) como en instalación on-premise. Es el estándar de facto en entornos corporativos que no pueden usar servicios externos. - **Fichero de configuración:** `.gitlab-ci.yml` (en la raíz del repositorio) - **Ejecutores:** GitLab Runners (muy versátiles: Linux, Windows, macOS, Kubernetes) - **Cuándo usarlo:** empresas con instalación on-premise, entornos con requisitos estrictos de seguridad (datos que no pueden salir de la red), corporaciones grandes. - **Punto fuerte:** todo en uno — registry de imágenes Docker, SAST/DAST, Kubernetes agent y plantillas corporativas reutilizables incluidos de serie. **Esqueleto mínimo:** ```yaml stages: - build - test - deploy build: stage: build image: maven:3.9-eclipse-temurin-17 script: - mvn clean package artifacts: paths: - target/*.jar test: stage: test image: maven:3.9-eclipse-temurin-17 script: - mvn test deploy: stage: deploy script: - echo "desplegando..." when: manual # ← gate manual (equivale al environment de GitHub Actions) allow_failure: false ``` ### Jenkins El veterano del CI/CD. Servidor autogestionado, altamente configurable mediante plugins. Sigue siendo el rey en empresas con infraestructura on-premise legacy o con flujos muy complejos que ningún SaaS puede cubrir. - **Fichero de configuración:** `Jenkinsfile` (en la raíz del repositorio, sintaxis Groovy) - **Ejecutores:** agents (nodos Jenkins, pods de Kubernetes, VMs, Docker) - **Cuándo usarlo:** organizaciones con monolitos o infraestructura propia, cuando se necesita personalización extrema o integración con sistemas legacy. - **Punto débil:** el “infierno de plugins” — actualizar Jenkins o sus plugins puede romper el pipeline; consume recursos incluso en reposo. **Esqueleto mínimo (Declarative Pipeline):** ```groovy pipeline { agent any stages { stage('Build') { steps { echo 'Compilando...' sh 'mvn clean package' } } stage('Test') { steps { sh 'mvn test' } } stage('Approval Gate') { steps { input message: '¿Aprobar despliegue a producción?' } } stage('Deploy') { steps { echo 'Desplegando...' } } } } ``` > **[Jenkins X](https://jayex.io/)** es una reescritura completa de Jenkins pensada para Kubernetes: usa GitOps de serie, crea entornos efímeros por Pull Request y delega la ejecución de pipelines en **[Tekton](https://tekton.dev/)** (framework de CI/CD nativo de Kubernetes). Es más complejo de operar pero elimina el problema de mantenimiento del servidor central. ### Tabla comparativa: ¿cuál elegir? | Herramienta | Dificultad | Mantenimiento | Cuándo elegirla | | --- | --- | --- | --- | | **GitHub Actions** | Baja | Casi nulo (SaaS) | Proyectos en GitHub, startups, open source, velocidad sin gestionar servidores | | **GitLab CI** | Baja–Media | Bajo si es SaaS; medio en on-premise | Entornos corporativos on-premise, requisitos de seguridad estrictos, todo en uno | | **Jenkins Classic** | Media–Alta | Alto | Infraestructura legacy, personalización extrema, sin posibilidad de usar cloud | | **Jenkins X** | Muy Alta | Medio (en Kubernetes) | Equipos 100% Kubernetes que quieren GitOps nativo y tienen DevOps dedicado | ## Más allá del CI: GitOps y herramientas de CD Los pipelines de CI (integración continua) se encargan de construir, probar y validar el código. Pero el **CD** (despliegue continuo) puede gestionarse con una filosofía diferente: **GitOps**. ### ¿Qué es GitOps? **Git como única fuente de verdad para el estado del sistema.** En el modelo tradicional, el pipeline “empuja” cambios al clúster (`kubectl apply`, `helm upgrade`). En GitOps, **nadie toca el clúster directamente**: cualquier cambio pasa por un commit en un repositorio Git. Un agente que vive dentro del clúster detecta la diferencia entre lo que dice Git y lo que hay desplegado, y lo sincroniza automáticamente. > Modelo Push (tradicional): CI pipeline → kubectl apply → clúster > Modelo Pull (GitOps): commit en Git → agente detecta → clúster se sincroniza solo ### ArgoCD y Flux: los agentes de GitOps - **[ArgoCD](https://argoproj.github.io/cd/)**: el más popular. Incluye interfaz web visual donde se ve el estado de todos los despliegues en tiempo real. Ideal para equipos que vienen del mundo Java/Spring Boot o que prefieren visibilidad gráfica. - **[Flux](https://fluxcd.io/)**: sin interfaz, más ligero, se integra de forma más transparente. Preferido por equipos de infraestructura. **Flujo híbrido recomendado** (el más extendido en empresas modernas): > 1. GitHub Actions / GitLab CI → CI: compila, testea, construye imagen Docker > 2. CI actualiza la versión en el repositorio de configuración (Helm chart) > 3. ArgoCD / Flux detecta el cambio → despliega en Kubernetes automáticamente Este modelo separa claramente la responsabilidad: el CI valida el código; el CD gestiona el estado del entorno. [El siguiente artículo entra en el trabajo previo al pipeline: la estrategia de ramas, el flujo de trabajo con IA y los Pull Requests.](https://jarroba.com/ci-cd-branching-git-flow-y-pull-requests/) ## Serie: CI/CD y la IA: De la teoría a la práctica 1. [CI/CD: Introducción — qué es, por qué importa y quién lo hace](https://jarroba.com/ci-cd-introduccion-que-es-por-que-importa-y-quien-lo-hace.md) 2. [CI/CD: Conceptos básicos — pipeline, job, stage, step y gates](https://jarroba.com/ci-cd-conceptos-basicos-pipeline-job-stage-step-y-gates.md) 3. [CI/CD: Branching, Git Flow y Pull Requests](https://jarroba.com/ci-cd-branching-git-flow-y-pull-requests.md) 4. [Pre-CI: Arquitectura general del pipeline CI/CD y comprobaciones previas](https://jarroba.com/pre-ci-arquitectura-general-del-pipeline-ci-cd-y-comprobaciones-previas.md) 5. [CI (Integración Continua): análisis, tests, calidad y seguridad](https://jarroba.com/ci-integracion-continua-analisis-tests-calidad-y-seguridad.md) 6. [CD (Entrega Continua) — Parte 1: empaquetado, SBOM y remediación](https://jarroba.com/cd-entrega-continua-parte-1-empaquetado-sbom-y-remediacion.md) 7. [CD (Entrega Continua) — Parte 2: Image Scan y Service Tests](https://jarroba.com/cd-entrega-continua-parte-2-image-scan-y-service-tests.md) 8. [CD (Entrega Continua) — Parte 3: Deploy a Dev y Smoke Tests](https://jarroba.com/cd-entrega-continua-parte-3-deploy-a-dev-y-smoke-tests.md) 9. [CD (Entrega Continua) — Parte 4: Deploy a Staging y Performance Smoke Tests](https://jarroba.com/cd-entrega-continua-parte-4-deploy-a-staging-y-performance-smoke-tests.md) 10. [CD (Entrega Continua) — Parte 5: LCA — Load, Stress y Chaos Engineering](https://jarroba.com/cd-entrega-continua-parte-5-lca-load-stress-y-chaos-engineering.md) 11. [CD (Entrega Continua) — Parte 6: Validaciones finales, Manual Approval y Deploy a Producción](https://jarroba.com/cd-entrega-continua-parte-6-validaciones-finales-manual-approval-y-deploy-a-produccion.md)