CI/CD para QA: GitHub Actions, Jenkins y GitLab Comparados

Los tests que solo corren en tu computadora no bloquean nada. Un desarrollador puede mergear código que rompe tu suite de tests y no te vas a enterar hasta que los ejecutes manualmente. Este artículo cubre cómo conectar los tests de Playwright a GitHub Actions, GitLab CI y Jenkins para que corran automáticamente en cada pull request, con un workflow de GitHub Actions listo para copiar y pegar y las diferencias de configuración entre las tres plataformas.

Qué significa CI/CD para QA

CI significa Integración Continua. La idea: cada vez que un desarrollador sube código, un proceso automatizado corre, compila el código, ejecuta los tests y reporta los resultados. Los problemas se detectan minutos después de introducirse, no días después durante el QA manual.

CD significa Entrega Continua (o Despliegue Continuo). Después de que CI pasa, el código se despliega automáticamente a un entorno de staging, o incluso a producción.

Para un ingeniero QA, la parte relevante es CI. Tus tests corren en el pipeline. Cada pull request los activa. Si los tests fallan, el PR no puede mergearse. Ese es el contrato.

Los tests que solo corren en tu computadora no hacen cumplir nada. Los tests en CI hacen cumplir el estándar de calidad en cada cambio, automáticamente.

GitHub Actions: empezá por acá

GitHub Actions es la herramienta de CI más fácil de aprender y la más usada en proyectos nuevos. Es gratuita para repositorios públicos y tiene un nivel gratuito generoso para los privados.

El concepto: defines un workflow en un archivo YAML dentro de tu repositorio. GitHub ejecuta ese workflow cuando ocurre un evento desencadenante: un push, un pull request, un horario programado.

Crea .github/workflows/playwright.yml en la raíz de tu proyecto:

mkdir -p .github/workflows

# .github/workflows/playwright.yml
name: Playwright Tests

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

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout del código
        uses: actions/checkout@v4

      - name: Configurar Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'

      - name: Instalar dependencias
        run: npm ci

      - name: Instalar navegadores de Playwright
        run: npx playwright install --with-deps

      - name: Ejecutar tests de Playwright
        run: npx playwright test

      - name: Subir reporte de tests
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: playwright-report
          path: playwright-report/
          retention-days: 14

Commitea este archivo, súbelo a GitHub y abre la pestaña Actions. Vas a ver el workflow corriendo. Instala Node, instala los navegadores de Playwright, ejecuta tus tests y sube el reporte HTML como un artefacto descargable.

El if: always() en el paso de subida significa que el reporte se sube incluso cuando los tests fallan, que es exactamente cuando más lo necesitas.

Entender el archivo de workflow

Variables de entorno en GitHub Actions

Nunca hardcodees credenciales en el archivo de workflow. Guárdalas como Secrets de GitHub y referencialas como variables de entorno.

Anda a tu repositorio → Settings → Secrets and variables → Actions → New repository secret. Agrega TEST_USER y TEST_PASS.

Referencialas en el workflow:

      - name: Ejecutar tests de Playwright
        run: npx playwright test
        env:
          TEST_USER: ${{ secrets.TEST_USER }}
          TEST_PASS: ${{ secrets.TEST_PASS }}
          BASE_URL: https://lab.becomeqa.com

En tus tests, accedelas con process.env.TEST_USER. Los secrets están enmascarados en los logs. GitHub reemplaza sus valores con * si aparecen en el output.

Corré los tests más rápido con sharding

Por defecto Playwright usa múltiples workers en una sola máquina. Para suites grandes, puedes dividirlos entre múltiples máquinas usando sharding.

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        shard: [1, 2, 3, 4]

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test --shard=${{ matrix.shard }}/4

Esto ejecuta 4 jobs en paralelo, cada uno manejando el 25% de los tests. Un suite que tarda 20 minutos en una máquina tarda 5 minutos dividido entre cuatro.

GitLab CI

GitLab CI usa los mismos conceptos que GitHub Actions pero con sintaxis diferente. El archivo de configuración es .gitlab-ci.yml en la raíz del proyecto.

# .gitlab-ci.yml
image: mcr.microsoft.com/playwright:v1.44.0-jammy

stages:
  - test

playwright:
  stage: test
  script:
    - npm ci
    - npx playwright test
  artifacts:
    when: always
    paths:
      - playwright-report/
    expire_in: 1 week
  variables:
    TEST_USER: $TEST_USER
    TEST_PASS: $TEST_PASS

Diferencias clave con GitHub Actions:

El campo image: especifica una imagen Docker para el job. Usar la imagen oficial de Playwright (mcr.microsoft.com/playwright) significa que los navegadores ya están instalados, así que no se necesita npx playwright install.

Las variables se configuran en GitLab → Project → Settings → CI/CD → Variables. Se referencian con $NOMBRE_VARIABLE en la config.

Si conoces GitHub Actions, puedes aprender GitLab CI en un día. El modelo mental es idéntico: activadores, jobs, pasos, artefactos. Solo diferente YAML.

Jenkins

Jenkins es más antiguo, más complejo y sigue siendo dominante en grandes entornos empresariales. Lo vas a encontrar en empresas con infraestructura legacy.

Jenkins usa un Jenkinsfile en la raíz del proyecto:

pipeline {
  agent {
    docker {
      image 'mcr.microsoft.com/playwright:v1.44.0-jammy'
    }
  }

  environment {
    TEST_USER = credentials('test-user')
    TEST_PASS = credentials('test-pass')
  }

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

    stage('Test') {
      steps {
        sh 'npx playwright test'
      }
      post {
        always {
          publishHTML(target: [
            reportDir: 'playwright-report',
            reportFiles: 'index.html',
            reportName: 'Playwright Report'
          ])
        }
      }
    }
  }
}

Jenkins requiere un servidor Jenkins funcionando. No es un servicio en la nube. Alguien necesita instalarlo, configurarlo y mantenerlo. Por eso GitHub Actions lo reemplazó en gran medida para los proyectos nuevos.

Para QA específicamente: si te unís a una empresa que usa Jenkins, no necesitás entender la administración de Jenkins. Necesitás entender la sintaxis del Jenkinsfile lo suficiente para agregar o modificar etapas de tests. El DSL del pipeline (la sintaxis de arriba) es con lo que los ingenieros QA trabajan día a día.

Qué herramienta aprender primero

La decisión es directa:

Cómo se ve un pipeline de CI real

Un pipeline maduro de Playwright en un proyecto real típicamente tiene más que solo "correr tests":

# Pipeline realista de producción
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx tsc --noEmit        # verificación de tipos TypeScript
      - run: npx eslint tests/       # lint de los archivos de tests

  test:
    needs: lint
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20, cache: 'npm' }
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test --project=chromium  # feedback rápido en un navegador
        env:
          BASE_URL: ${{ vars.BASE_URL }}
          TEST_USER: ${{ secrets.TEST_USER }}
          TEST_PASS: ${{ secrets.TEST_PASS }}
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: playwright-report
          path: playwright-report/

  test-cross-browser:
    needs: test
    if: github.ref == 'refs/heads/main'  # solo en la rama main
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20, cache: 'npm' }
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test  # todos los navegadores

El patrón: feedback rápido primero (lint + Chromium), luego cross-browser completo en la rama main. Los pull requests reciben resultados rápidos; los merges reciben cobertura exhaustiva.

FAQ

Verifica tres cosas: variables de entorno (secrets no configurados en Actions), base URL (localhost hardcodeado que no existe en CI), y timing (los runners de CI son más lentos, así que agregá retries: 1 en playwright.config.ts para CI).

En GitHub Actions: anda a la ejecución fallida → Summary → Artifacts → descarga playwright-report. Extrae el zip y abre index.html en un navegador.

No de forma nativa en Playwright. Algunos equipos usan filtrado por ruta: correr solo los tests en tests/auth/ cuando cambiaron archivos en src/auth/. Es complejo de configurar de forma confiable. Empieza corriendo el suite completo y optimiza después si se vuelve muy lento.

Agregá un activador de horario:

on:
  schedule:
    - cron: '0 2 * * *'   # 2am UTC todas las noches
  push:
    branches: [main]

Las ejecuciones nocturnas son útiles para detectar fallos intermitentes que no aparecen en cada ejecución de PR.