Preguntas de Entrevista sobre Pipelines CI/CD: GitHub Actions, GitLab CI y Jenkins en 2026

Las preguntas de entrevista sobre pipelines CI/CD se encuentran entre los temas más frecuentes en los procesos de contratación DevOps en 2026. Con GitHub Actions procesando más de 71 millones de jobs por día y lanzando la ejecución paralela de steps en junio 2026, GitLab CI alcanzando la versión 19 con su Secrets Manager nativo, y Jenkins manteniendo un 28% de tasa de adopción, los entrevistadores esperan que los candidatos demuestren dominio práctico en las tres plataformas.

Estructura de Workflows y Triggers en GitHub Actions

GitHub Actions organiza la automatización en torno a workflows, jobs y steps. Un workflow es un archivo YAML almacenado en .github/workflows/ que define cuándo y cómo se ejecuta la automatización. Cada workflow contiene uno o más jobs, y cada job se ejecuta en un runner separado.

Una pregunta de entrevista común pide a los candidatos explicar la relación entre los triggers on, las dependencias de jobs y la palabra clave needs.

# .github/workflows/ci.yml
name: CI Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint

  test:
    needs: lint              # waits for lint to pass
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [20, 22]       # runs tests on both versions
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
          cache: npm
      - run: npm ci
      - run: npm test

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production  # requires approval
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh

Este workflow demuestra tres conceptos clave: la palabra clave needs crea un grafo de dependencias entre jobs, la estrategia matrix permite probar en paralelo en múltiples versiones de Node.js, y la palabra clave environment condiciona los despliegues a aprobación manual.

Steps Paralelos en GitHub Actions

GitHub Actions lanzó la ejecución paralela de steps el 25 de junio de 2026, abordando una de las características más solicitadas. Anteriormente, todos los steps dentro de un job se ejecutaban secuencialmente. La nueva funcionalidad introduce cuatro palabras clave que permiten ejecución concurrente dentro de un solo job.

# .github/workflows/parallel-steps.yml
name: Build with Parallel Steps

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci

      # Run lint and typecheck in parallel
      - name: lint
        run: npm run lint
        background: true

      - name: typecheck
        run: npm run typecheck
        background: true

      - wait-all:              # wait for both to complete

      # Or use the parallel shorthand
      - parallel:
          - name: build-frontend
            run: npm run build:frontend
          - name: build-backend
            run: npm run build:backend

      - run: npm run deploy

La palabra clave background: true inicia un step de forma asíncrona y continúa inmediatamente al siguiente step. La palabra clave wait-all pausa la ejecución hasta que todos los steps en segundo plano se completen. La palabra clave parallel proporciona una sintaxis abreviada que ejecuta múltiples steps simultáneamente y espera a que todos terminen antes de continuar.

Existen dos palabras clave adicionales: wait apunta a steps nombrados específicos en segundo plano, y cancel termina elegantemente un step en segundo plano cuando ya no es necesario (útil para detener servicios de larga ejecución).

Configuración de Pipeline GitLab CI con Stages

GitLab CI usa un archivo .gitlab-ci.yml en la raíz del repositorio. A diferencia de GitHub Actions donde los jobs se ejecutan independientemente por defecto, GitLab CI organiza los jobs en stages que se ejecutan secuencialmente, mientras que los jobs dentro del mismo stage se ejecutan en paralelo.

Los entrevistadores frecuentemente piden a los candidatos convertir un workflow de GitHub Actions en un pipeline de GitLab CI, o viceversa.

# .gitlab-ci.yml
stages:
  - validate
  - test
  - deploy

variables:
  NODE_VERSION: "22"

lint:
  stage: validate
  image: node:${NODE_VERSION}
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/
  script:
    - npm ci
    - npm run lint

unit-tests:
  stage: test
  image: node:${NODE_VERSION}
  parallel:
    matrix:
      - NODE_VERSION: ["20", "22"]
  script:
    - npm ci
    - npm test
  artifacts:
    reports:
      junit: coverage/junit.xml
    expire_in: 7 days

deploy-production:
  stage: deploy
  image: alpine:latest
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual                   # manual gate
  environment:
    name: production
    url: https://app.example.com
  script:
    - ./deploy.sh

Diferencias clave con GitHub Actions: los stages imponen orden de ejecución globalmente, la palabra clave parallel:matrix maneja builds matriciales, y artifacts:reports:junit integra los resultados de tests directamente en las vistas de merge request.

GitLab 19.0 (mayo 2026) introdujo el Secrets Manager en open beta, proporcionando almacenamiento nativo de secrets sin servicios externos como HashiCorp Vault. GitLab 19.2 (julio 2026) hizo las políticas de ejecución de pipelines programados generalmente disponibles, permitiendo a los equipos imponer escaneos de cumplimiento o verificaciones de dependencias en una cadencia fija a través de múltiples proyectos desde una sola definición de política.

Sintaxis de Pipeline Declarativo en Jenkins

Jenkins usa un Jenkinsfile almacenado en la raíz del repositorio. La sintaxis de pipeline declarativo, recomendada como estándar en 2026, proporciona manejo estructurado de errores y una disposición clara basada en stages.

Una pregunta de entrevista frecuente: explicar la diferencia entre pipelines declarativos y con script, y cuándo usar cada uno.

// Jenkinsfile
pipeline {
    agent any

    tools {
        nodejs 'node-22'       // configured in Jenkins Global Tool
    }

    environment {
        CI = 'true'
        DEPLOY_ENV = credentials('deploy-env-secret')
    }

    stages {
        stage('Install') {
            steps {
                sh 'npm ci'
            }
        }

        stage('Lint & Test') {
            parallel {             // parallel execution
                stage('Lint') {
                    steps {
                        sh 'npm run lint'
                    }
                }
                stage('Test') {
                    steps {
                        sh 'npm test'
                    }
                    post {
                        always {
                            junit 'coverage/junit.xml'
                        }
                    }
                }
            }
        }

        stage('Deploy') {
            when {
                branch 'main'
            }
            input {
                message 'Deploy to production?'
            }
            steps {
                sh './deploy.sh'
            }
        }
    }

    post {
        failure {
            mail to: 'team@example.com',
                 subject: "Build failed: ${env.JOB_NAME}",
                 body: "Check ${env.BUILD_URL}"
        }
    }
}

Los pipelines declarativos imponen estructura a través de bloques obligatorios pipeline, agent y stages. La directiva parallel dentro de un stage ejecuta lint y test simultáneamente. La directiva input pausa la ejecución para aprobación manual, similar a los environments de GitHub Actions y las puertas manuales de GitLab. Jenkins requiere Java 21 desde enero 2026, por lo que los entornos de pipeline deben considerar esta dependencia de runtime.

Gestión de Secrets en Plataformas CI/CD

Toda entrevista de CI/CD incluye preguntas sobre gestión de secrets. Cada plataforma maneja las credenciales de manera diferente, y entender las implicaciones de seguridad es fundamental.

GitHub Actions almacena secrets a nivel de repositorio, environment u organización. Los secrets se enmascaran automáticamente en los logs, pero el modelo de alcance actual tiene limitaciones. El roadmap de seguridad 2026 introduce secrets con alcance que vinculan credenciales a contextos de ejecución explícitos, abordando el riesgo de acceso excesivamente amplio.

GitLab CI proporciona variables CI/CD con reglas de protección. Las variables protegidas solo se inyectan en pipelines que se ejecutan en branches o tags protegidos. GitLab 19.0 introdujo el Secrets Manager, permitiendo a los equipos almacenar y referenciar secrets nativamente sin vaults externos. Los secrets tienen alcance a proyectos o grupos y son accesibles solo para jobs que los solicitan explícitamente.

Jenkins usa el plugin Credentials con múltiples tipos de credenciales (usuario/contraseña, clave SSH, texto secreto, certificado). El helper credentials() en pipelines declarativos vincula secrets a variables de entorno, y las credenciales a nivel de Folder limitan el acceso a proyectos específicos.

La respuesta crítica en entrevista: nunca codificar secrets en archivos de pipeline, siempre usar la gestión nativa de secrets de la plataforma, rotar credenciales regularmente, y preferir tokens de corta duración sobre claves API de larga duración.

Optimización de Pipeline y Estrategias de Caching

Los pipelines lentos impactan directamente la productividad de los desarrolladores. Los entrevistadores evalúan si los candidatos pueden diagnosticar y corregir cuellos de botella de rendimiento en sistemas CI/CD.

Tres técnicas de optimización universales se aplican en las tres plataformas:

Caching de dependencias evita re-descargar paquetes en cada ejecución. GitHub Actions usa actions/cache o soporte de cache integrado en las actions de setup. GitLab CI usa cache con una estrategia de clave. Jenkins depende de la persistencia del workspace o los comandos stash/unstash.

Ejecución paralela divide el trabajo entre múltiples runners. GitHub Actions ahora soporta tanto jobs paralelos (estrategia matrix) como steps paralelos (palabras clave background/parallel). GitLab CI usa parallel:matrix, y Jenkins usa la directiva parallel. La granularidad correcta de división depende del proyecto: demasiados jobs paralelos desperdician tiempo de inicio de runners, muy pocos dejan capacidad sin usar.

Ejecución condicional omite stages innecesarios. Las tres plataformas lo soportan: GitHub Actions con expresiones if, GitLab CI con rules, y Jenkins con directivas when. Un pipeline bien diseñado omite stages de despliegue en branches de feature y omite activar suites completas de tests para cambios solo de lint.

Seguridad y Protección de la Supply Chain CI/CD

Los ataques a la supply chain dirigidos a sistemas CI/CD aumentaron significativamente en 2025, con incidentes afectando a tj-actions/changed-files y otras GitHub Actions populares. Las preguntas de entrevista ahora regularmente evalúan a los candidatos sobre estrategias de endurecimiento.

Fijar versiones de actions a SHAs de commit específicos en lugar de tags para prevenir ataques de tag-hijacking:

# .github/workflows/secure.yml
steps:
  # Vulnerable: tag can be moved to malicious commit
  - uses: actions/checkout@v4

  # Secure: pinned to exact commit SHA
  - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683

GitLab CI aborda las preocupaciones de supply chain a través de componentes CI/CD con atestación SLSA Level 1 (disponible desde GitLab 18.1), proporcionando proveniencia más clara al ensamblar pipelines desde componentes reutilizables. Los tags de contenedor inmutables (GitLab 18.2) previenen el reemplazo de imágenes después de la publicación.

Para Jenkins, el mecanismo de Shared Library debe usar un repositorio dedicado con protección de branch, requisitos de revisión de código y commits firmados. La Comisión Europea lanzó un programa de Bug Bounty de Jenkins a través de YesWeHack, reflejando el rol crítico de la plataforma en las supply chains empresariales.

Comparación Cross-Platform para Preparación de Entrevistas

Esta tabla comparativa cubre las diferencias más comúnmente evaluadas en entrevistas. La pregunta de seguimiento típicamente pregunta: "¿Qué plataforma elegirías para un nuevo proyecto, y por qué?" La respuesta depende de las herramientas existentes, tamaño del equipo, requisitos de cumplimiento, y si la organización prefiere infraestructura gestionada (GitHub/GitLab) o control total (Jenkins).

Sources

• Actions steps can now be run in parallel (GitHub Changelog, junio 2026)
• GitLab 19.0 release notes (GitLab Docs, mayo 2026)
• GitLab 19.2 release notes (GitLab Docs, julio 2026)
• Jenkins Changelog (Jenkins.io, agosto 2026)
• GitHub Actions 2026 Security Roadmap (GitHub Blog)

Para practicar estas preguntas de forma práctica, consultar los módulos de fundamentos CI/CD y GitHub Actions, o explorar las preguntas específicas de GitLab CI y Jenkins. Para una preparación DevOps más amplia, la guía de preguntas esenciales de entrevista DevOps cubre el alcance completo de temas más allá de CI/CD.

Puntos Clave para Entrevistas de CI/CD Pipeline

• Los steps paralelos de GitHub Actions (background, wait-all, parallel) se lanzaron en junio 2026, permitiendo ejecución concurrente dentro de un solo job mientras comparten el runner, checkout y workspace
• GitLab 19.x introdujo el Secrets Manager nativo (open beta, mayo 2026) e hizo las políticas de ejecución de pipelines programados generalmente disponibles (julio 2026), reduciendo la dependencia de herramientas externas
• Jenkins 2.574+ desacopló plugins core incluyendo JUnit y Mailer del archivo WAR, requiriendo instalación explícita para instancias sin acceso al centro de actualizaciones
• La gestión de secrets es el tema de seguridad más evaluado en las tres plataformas: demostrar conocimiento de secrets con alcance, variables protegidas y estrategias de rotación de credenciales
• La optimización de pipelines a través de caching, paralelización y ejecución condicional se aplica universalmente y señala experiencia práctica en producción a los entrevistadores
• Preparar al menos una configuración de pipeline funcional por plataforma, enfocándose en patrones del mundo real en lugar de ejemplos de juguete