Guía Paso a Paso: CI/CD para Frontend con GitHub Actions y Despliegue Automatizado

El despliegue manual de software mediante FTP o arrastrando archivos por SSH es una de las mayores fuentes de errores en la industria del desarrollo web. Un archivo olvidado, una versión equivocada de Node.js o una variable de entorno desincronizada pueden dejar una aplicación en caída libre (downtime) en plena hora punta.

La solución es clara: Integración Continua (CI) y Despliegue Continuo (CD). Cada vez que un desarrollador hace un git push a la rama main, una máquina aislada en la nube clona el repositorio, valida el formato del código, ejecuta los tests unitarios, compila los activos estáticos y despliega la nueva versión a producción de manera atómica y sin interrupción del servicio.

En esta guía detallamos cómo configurar un pipeline profesional para aplicaciones frontend utilizando GitHub Actions.

1. La Arquitectura de un Pipeline Frontend Profesional

Un buen pipeline de CI/CD para frontend debe cumplir tres premisas:

1. Velocidad (Fast Feedback): Si el pipeline tarda más de 3-4 minutos, los desarrolladores perderán el ritmo y dejarán de revisar los resultados antes de cambiar de contexto.
2. Determinismo: Utilizar npm ci en lugar de npm install para garantizar que se instalan exactamente las mismas dependencias descritas en el archivo de bloqueo package-lock.json.
3. Resiliencia (Fail-Fast): Si los linters fallan o hay un error de TypeScript, el proceso se detiene inmediatamente sin gastar minutos de cómputo intentando compilar.

2. El Archivo de Configuración .github/workflows/deploy.yml

A continuación presentamos el workflow completo y optimizado que utilizamos en proyectos basados en Astro y Angular para desplegar en GitHub Pages con dominio personalizado:

name: Deploy Frontend to Production

on:
  push:
    branches: [ main ]
  workflow_dispatch:

permissions:
  contents: read
  pages: write
  id-token: write

concurrency:
  group: "pages"
  cancel-in-progress: false

jobs:
  build:
    name: Build & Validate
    runs-on: ubuntu-latest
    steps:
      - name: Clonar Repositorio
        uses: actions/checkout@v4

      - name: Configurar Node.js (v22 LTS)
        uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: 'npm'

      - name: Instalar Dependencias Deterministas
        run: npm ci

      - name: Verificación Estricta de Tipos TypeScript
        run: npx astro check || npx tsc --noEmit

      - name: Compilación de Producción
        run: npm run build

      - name: Subir artefactos estáticos
        uses: actions/upload-pages-artifact@v3
        with:
          path: ./dist

  deploy:
    name: Despliegue Atómico
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Desplegar en GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4

3. Caching Inteligente: Reducir el tiempo de build de 5 minutos a 45 segundos

Uno de los cuellos de botella habituales en GitHub Actions es la descarga reiterada de la carpeta node_modules.

Mediante la propiedad cache: 'npm' en la acción oficial actions/setup-node@v4, GitHub Actions guarda una instantánea de la caché de paquetes indexada por el hash del archivo package-lock.json. Si no se ha añadido ninguna biblioteca nueva, la instalación de dependencias se resuelve en cuestión de segundos:

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

4. Gestión de Dominios Personalizados y HTTPS (.es)

Al desplegar en GitHub Pages con un dominio propio (como jaumetur.es), hay que tener en cuenta dos aspectos críticos:

1. El archivo CNAME en la carpeta de salida: GitHub Pages requiere un archivo de texto llamado CNAME que contenga exclusivamente el dominio de producción. En Astro, simplemente se guarda en /public/CNAME.
2. El archivo .nojekyll: GitHub Pages asume por defecto que los sitios están construidos con Jekyll, ignorando cualquier carpeta que empiece por guión bajo (_astro, _app). Crear un archivo vacío /public/.nojekyll desactiva este comportamiento y garantiza que todos los recursos CSS y JavaScript carguen correctamente.

Conclusión

La automatización mediante CI/CD transforma la seguridad psicológica de un equipo de ingeniería. Saber que cada cambio pasa por una batería de validaciones automáticas permite entregar valor continuamente sin miedo a romper la producción.

Si quieres implementar un pipeline similar en tu organización o reducir los tiempos de despliegue de tu equipo, puedes solicitar nuestro servicio de consultoría DevOps.