GitHub Actions para CI/CD: de cero a un pipeline listo para producción

GitHub Actions se ha convertido en una de las formas más rápidas de montar CI/CD sin infraestructura adicional: vive donde ya está tu código. En esta guía te cuento los conceptos clave y montamos un pipeline realista, con los trucos que uso en proyectos de producción.

Conceptos básicos

• Workflow: un fichero YAML en .github/workflows/ que se dispara con eventos (push, pull request, cron…).
• Job: conjunto de pasos que se ejecutan en un runner. Los jobs pueden ir en paralelo o encadenados con needs.
• Step: un comando o una action reutilizable del marketplace.
• Runner: la máquina que ejecuta el job, hospedada por GitHub o propia (self-hosted).

Un pipeline CI básico

name: ci
on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    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 test
      - run: npm run lint

Con esto ya tienes validación automática en cada pull request. La clave está en el cache: npm: reutilizar dependencias entre ejecuciones puede reducir el tiempo del pipeline a la mitad.

Despliegue con OIDC (sin secretos estáticos)

El error clásico es guardar claves de AWS o Azure como secretos de larga duración. La alternativa moderna es OIDC: el workflow se autentica contra tu nube con un token temporal y un rol con permisos mínimos.

  deploy:
    needs: test
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/deploy-role
          aws-region: eu-west-1
      - run: ./scripts/deploy.sh

Buenas prácticas que aplico siempre

• Fija versiones de las actions (mejor por SHA que por tag) para evitar sorpresas de supply chain.
• Entornos con aprobación: usa environments con revisores obligatorios para producción.
• Matrices para probar en varias versiones de lenguaje o sistema a la vez.
• Concurrency: cancela ejecuciones obsoletas del mismo PR con concurrency y ahorra minutos de runner.
• Workflows reutilizables: centraliza la lógica común en un repositorio y llámala con workflow_call.

Conclusión

GitHub Actions baja muchísimo la barrera de entrada al CI/CD, pero un pipeline de producción exige lo mismo de siempre: permisos mínimos, versiones fijadas, cachés bien usadas y aprobaciones donde toca. Empieza simple y evoluciona el pipeline igual que evolucionas tu código.

¿Usas GitHub Actions, GitLab CI u otra herramienta? Te leo en los comentarios. 😊