Pipeline CI/CD para JavaScript: configuración desde cero en 10 pasos

Cómo dejar de desplegar manualmente y no temer a los commits

¿Alguna vez te has sentado un viernes por la noche, mirando la producción y pensando: "Bueno, parece que todo funciona, ¿y si ejecuto la compilación ahora, no se romperá nada?" ¿Te suena familiar? El despliegue manual es como saltar en paracaídas sin instructor: tiene su adrenalina, pero demasiado a menudo termina mal.

El pipeline CI/CD es tu cuerda de seguridad automática. Él mismo compilará el proyecto, ejecutará las pruebas, revisará el código y, si todo está bien, lanzará la actualización al servidor. Nada de "ay, olvidé ejecutar la compilación" o "¿por qué fallaron las pruebas si funcionaban localmente?".

En este artículo configuraremos desde cero un pipeline CI/CD completo para un proyecto JavaScript. Sin rodeos, con ejemplos de código reales y configuraciones listas. ¡Allá vamos!

Qué es un pipeline CI/CD y por qué lo necesita un desarrollador JavaScript

Aclaremos los términos de inmediato para no confundirnos.

Continuous Integration (CI) — integración continua. Significa que cada uno de tus commits se verifica automáticamente: el código pasa por linters, pruebas y compilación. Si algo se rompe, te enteras en 2 minutos, no en una semana.

Continuous Delivery (CD) — entrega continua. Despliegue automático del código listo en el servidor después de que todas las verificaciones de CI hayan sido exitosas.

Para proyectos JavaScript, CI/CD es especialmente importante. ¿Por qué? Porque el ecosistema JS tiene miles de dependencias que pueden actualizarse en cualquier momento y romper tu código. La automatización te salva de esas sorpresas.

Qué vamos a configurar

\n
• GitHub Actions — herramienta gratuita para CI/CD (suficiente para la mayoría de proyectos)
\n
• Linter — verificación del estilo del código (ESLint)
\n
• Pruebas — ejecución automática de Jest
\n
• Compilación — build del proyecto (Webpack o Vite)
\n
• Despliegue — subida automática al servidor o hosting
\n

Paso 1: Preparar el proyecto

Supongamos que ya tienes un proyecto JavaScript (React, Vue, Node.js — no importa). Si no, crea un proyecto simple para probar:

mkdir my-ci-cd-project\ncd my-ci-cd-project\nnpm init -y\nnpm install --save-dev jest eslint

Añadimos un script básico en package.json:

{\n  "scripts": {\n    "test": "jest",\n    "lint": "eslint src/",\n    "build": "webpack --mode production",\n    "deploy": "rsync -avz dist/ user@server:/var/www"\n  }\n}

Ahora tenemos comandos locales que el CI/CD ejecutará automáticamente.

Paso 2: Crear el workflow de GitHub Actions

GitHub Actions es el cerebro de nuestro pipeline. Todo se gestiona con archivos YAML en la carpeta .github/workflows/.

Crea el archivo .github/workflows/ci-cd.yml:

name: CI/CD Pipeline\n\non:\n  push:\n    branches: [ main, develop ]\n  pull_request:\n    branches: [ main ]\n\njobs:\n  build-and-test:\n    runs-on: ubuntu-latest\n    \n    steps:\n    - uses: actions/checkout@v3\n    \n    - name: Setup Node.js\n      uses: actions/setup-node@v3\n      with:\n        node-version: '18'\n        \n    - name: Install dependencies\n      run: npm ci\n      \n    - name: Run linter\n      run: npm run lint\n      \n    - name: Run tests\n      run: npm test\n      \n    - name: Build project\n      run: npm run build

¿Qué sucede aquí? Con cada push a main o develop, GitHub inicia una máquina virtual con Ubuntu, instala Node.js 18, instala las dependencias (instalación limpia con npm ci — más rápida y confiable que npm install), verifica el código con el linter, ejecuta las pruebas y compila el proyecto.

Si algún paso falla, el pipeline se detiene y recibes una notificación.

Paso 3: Añadir linter y pruebas

ESLint y Jest son el estándar para JavaScript. Los configuraremos pa