CI/CD: Conceptos básicos — pipeline, job, stage, step y gates

📚 Serie: CI/CD y la IA: De la teoría a la práctica

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, GitLab CI y Jenkins.

Índice

• Pipeline
• Gates (puertas de calidad)
• Job (tarea)
• Stage (fase) y Step (paso)
• Tabla de equivalencias
• Ejemplos con código

---

Pipeline

Un pipeline es un conjunto de stages (etapas) que se ejecutan en secuencia para construir, probar, desplegar y mantener un producto software.

---

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.

El gate más conocido quizás sea el gate de 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, 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.

---

Tabla de equivalencias entre GitHub Actions, GitLab CI y Jenkins

La nomenclatura varía entre herramientas, pero los conceptos son equivalentes:

---

Ejemplos con código

Pipeline con gate de aprobación manual

Jenkins (se guarda en un archivo Jenkinsfile; documentación de Jenkinsfile aquí ):

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í ):

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í ):

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/<nombre>.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:

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:

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):

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 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 (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?

---

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: 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: 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.