CI/CD para proyectos JavaScript: GitHub Actions de la A a la Z

Introducción: ¿Por qué necesitas CI/CD para proyectos JavaScript?

El desarrollo de aplicaciones JavaScript modernas en Node.js requiere no solo escribir código de calidad, sino también entregarlo de manera confiable a los usuarios finales. Las pruebas, compilación e implementación manuales no solo son lentas, sino que también son propensas a errores humanos. Aquí es donde entra en juego CI/CD (Integración Continua / Despliegue Continuo), una metodología para automatizar todas las etapas del ciclo de vida del software.

CI/CD para proyectos JavaScript permite ejecutar pruebas automáticamente con cada push al repositorio, compilar la aplicación y desplegarla en un servidor o en la nube. Una de las herramientas más populares para implementar esta metodología es GitHub Actions, un sistema de automatización de flujos de trabajo integrado en la plataforma GitHub.

En este artículo, analizaremos cómo configurar un pipeline completo de CI/CD para un proyecto JavaScript (Node.js) usando GitHub Actions: desde escribir la configuración hasta el despliegue. Aprenderás cómo acelerar el desarrollo, mejorar la calidad del código y olvidarte de las operaciones rutinarias.

Parte principal: Creación de un pipeline CI/CD con GitHub Actions

1. ¿Qué es GitHub Actions y cómo funciona?

GitHub Actions es una plataforma para automatizar flujos de trabajo (workflows) que se ejecutan en respuesta a eventos en el repositorio (push, pull request, creación de issues, etc.). Un workflow es un conjunto de pasos que se ejecutan en máquinas virtuales (runners). Cada paso puede ejecutar scripts, instalar dependencias o llamar a servicios externos.

Conceptos principales:

\n
• Workflow — archivo de configuración YAML almacenado en la carpeta .github/workflows/.
\n
• Event — desencadenante que inicia el workflow (por ejemplo, push o pull_request).
\n
• Job — conjunto de pasos que se ejecutan en un mismo runner (dependencias, pruebas, compilación).
\n
• Step — comando o acción individual (action).
\n

Para proyectos JavaScript, usaremos el runner estándar con Ubuntu, ya que admite Node.js de forma nativa.

2. Configuración básica: Pruebas y linting

Comencemos creando un workflow simple para pruebas y linting del código. Crea un archivo .github/workflows/ci.yml en la raíz de tu repositorio.

Ejemplo de configuración para un proyecto Node.js:

name: CI for Node.js\n\non:\n  push:\n    branches: [ main, develop ]\n  pull_request:\n    branches: [ main ]\n\njobs:\n  test:\n    runs-on: ubuntu-latest\n\n    strategy:\n      matrix:\n        node-version: [18.x, 20.x]\n\n    steps:\n      - name: Checkout repository\n        uses: actions/checkout@v4\n\n      - name: Setup Node.js ${{ matrix.node-version }}\n        uses: actions/setup-node@v4\n        with:\n          node-version: ${{ matrix.node-version }}\n          cache: 'npm'\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

Analicemos los puntos clave:

\n
• Matrix strategy — permite ejecutar pruebas en varias versiones de Node.js (18.x y 20.x) en paralelo.
\n
• actions/checkout — acción estándar para clonar el repositorio.
\n
• actions/setup-node — instala la versión requerida de Node.js y habilita el almacenamiento en caché de node_modules para acelerar el proceso.
\n
• npm ci — instalación limpia de dependencias desde package-lock.json (más rápido y confiable que npm install).
\n

Después de hacer push de este archivo al repositorio, GitHub Actions ejecutará automáticamente las pruebas. Verás el resultado en la sección "Actions" de tu repositorio.

3. Compilación y publicación de una imagen Docker

E