Automatiza tu workflow con GitHub Actions

Aprende a automatizar tus tareas de desarrollo con GitHub Actions: ejemplos prácticos, consejos y trucos para optimizar tu flujo de trabajo.

Cuando hablamos de automatizar el workflow de desarrollo, GitHub Actions se ha convertido en una herramienta imprescindible. No importa si trabajas solo o en equipo, poder lanzar tests, builds o despliegues automáticamente al hacer push te ahorra horas de trabajo manual y errores tontos. Aquí te cuento cómo sacarle partido sin volverte loco en el intento.

Lo básico: estructura de un workflow

Un workflow se define en un archivo YAML dentro de .github/workflows/. Cada archivo representa una automatización que se dispara por eventos como push, pull_request o incluso un horario programado. La estructura mínima es esta:

name: CI básico
on: [push]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Ejecutar tests
        run: npm test

Fíjate en que usamos actions/checkout para clonar el repositorio dentro del runner. Sin ese paso, no tienes acceso a tu código. Es el primer paso en casi cualquier workflow.

Ejemplo práctico: tests y lint automáticos

Imagina que tienes un proyecto Node.js. Quieres que cada vez que alguien haga un push a la rama main, se ejecuten los tests y el linter. Así lo haría yo:

name: Test y lint
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Configurar Node
        uses: actions/setup-node@v4
        with:
          node-version: '20'
      - name: Instalar dependencias
        run: npm ci
      - name: Lint
        run: npm run lint
      - name: Tests
        run: npm test

npm ci es clave aquí: instala las dependencias exactas del package-lock.json, evitando sorpresas. Y al separar lint y tests en pasos distintos, si falla uno, sabrás exactamente cuál es el problema.

Despliegue automático con secrets

Aquí es donde GitHub Actions brilla. Puedes desplegar a un servidor por SSH o publicar en un bucket de S3 sin exponer credenciales. Los secrets se guardan en Settings > Secrets and variables > Actions de tu repositorio.

Un ejemplo de despliegue a un VPS por SSH:

name: Deploy a producción
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Copiar archivos al servidor
        uses: appleboy/scp-action@v0.1.7
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          source: "dist/*"
          target: "/var/www/miweb"
      - name: Reiniciar servicio
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /var/www/miweb
            systemctl restart miweb.service

Nunca pongas contraseñas o claves directamente en el YAML. Si lo haces, las estarás exponiendo a cualquiera con acceso al repositorio.

Trucos y buenas prácticas

Caché de dependencias. Instalar paquetes cada vez es lento. Con actions/cache puedes guardar la carpeta node_modules y acelerar mucho tus runs:

- name: Cache de npm
  uses: actions/cache@v4
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}

Filtra eventos con cuidado. No quieres que el workflow de producción se lance con un cambio de documentación. Usa paths-ignore o paths para limitar qué archivos disparan la automatización.

Reutiliza con actions compuestas. Si tienes pasos repetidos en varios workflows, créate una action propia en una carpeta .github/actions/. Es como una función reutilizable para tus pipelines.

Conclusión

GitHub Actions no es solo para proyectos grandes; incluso un blog o un script personal se benefician de automatizar tareas repetitivas. Empieza con algo pequeño: un workflow que ejecute tus tests. Luego añade el despliegue. En una tarde tienes un pipeline decente que te ahorra dolores de cabeza cada vez que haces commit. Y recuerda: los logs de cada ejecución son tus mejores aliados para depurar cuando algo falle.