Pipelines CI/CD explicados con GitHub Actions

DevOps2026-09-12TryQuickToolBox

Acabas de hacer push de un commit y ahora estás ejecutando las pruebas manualmente, compilando la app y subiendo archivos a un servidor. Funciona, pero es lento, propenso a errores y no escala. Aquí es donde entran los pipelines CI/CD.

En esta guía, desglosaremos los conceptos de CI/CD y te mostraremos cómo construir un pipeline real con GitHub Actions. Al final, entenderás cómo automatizar pruebas, compilación y despliegue para cualquier proyecto.

¿Qué es CI/CD?

CI (Continuous Integration o integración continua) es la práctica de probar y fusionar automáticamente los cambios de código en una rama compartida. Cada push desencadena una compilación y ejecución de pruebas, detectando problemas de integración a tiempo.

CD (Continuous Delivery/Deployment o entrega/despliegue continuo) extiende CI preparando (y opcionalmente desplegando) automáticamente tu aplicación a producción. Continuous Delivery significa que el código siempre está listo para desplegarse; Continuous Deployment significa que se despliega automáticamente.

Juntos, CI/CD forma un pipeline: una serie de pasos automatizados que llevan tu código desde el commit hasta producción.

¿Por qué usar GitHub Actions para CI/CD?

GitHub Actions es una plataforma CI/CD integrada en GitHub. Es gratuita para repositorios públicos y ofrece minutos generosos para los privados. Beneficios clave:

Integrado: No se necesita un servicio externo; los workflows viven en tu repositorio.
Basado en eventos: Activa workflows con push, pull request, programación o ejecución manual.
Extensible: Miles de actions preconstruidas en el GitHub Marketplace.
Compilaciones matriciales: Prueba en múltiples SO y versiones de lenguaje fácilmente.

Conceptos clave de GitHub Actions

Antes de escribir tu primer workflow, entiende estos términos:

Término	Descripción
Workflow	Un proceso automatizado definido en un archivo YAML dentro de `.github/workflows/`.
Event	Un disparador que inicia un workflow (p. ej., `push`, `pull_request`).
Job	Un conjunto de pasos que se ejecutan en el mismo runner. Los jobs se ejecutan en paralelo por defecto.
Step	Una tarea individual dentro de un job. Puede ejecutar un comando o usar una action.
Action	Una unidad de código reutilizable (p. ej., `actions/checkout`) que puedes incluir en un step.
Runner	Una máquina virtual que ejecuta los jobs (Ubuntu, Windows, macOS).

Construyendo tu primer pipeline CI

Vamos a crear un workflow CI básico para un proyecto Node.js. Ejecutará pruebas en cada push y pull request a la rama main.

Crea .github/workflows/ci.yml:

name: CI

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

jobs:
  test:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [18.x, 20.x]

    steps:
    - uses: actions/checkout@v4
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v4
      with:
        node-version: ${{ matrix.node-version }}
    - run: npm ci
    - run: npm test

Este workflow:

Se activa con pushes y PRs a main.
Ejecuta un job llamado test en el runner Ubuntu más reciente.
Usa una matriz para probar con Node.js 18 y 20.
Hace checkout del código, configura Node, instala dependencias y ejecuta pruebas.

Haz push de este archivo y observa la pestaña Actions. Verás dos jobs en paralelo (uno por versión de Node). Si alguna prueba falla, el workflow falla y GitHub te notifica.

Añadiendo despliegue continuo

CI está genial, pero CD es donde la automatización brilla. Extendamos el workflow para desplegar a un servidor después de que las pruebas pasen en la rama main.

Añadiremos un job deploy que depende de test y se ejecuta solo con pushes a main.

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v4
    - name: Deploy to server
      uses: appleboy/ssh-action@v1.0.0
      with:
        host: ${{ secrets.SSH_HOST }}
        username: ${{ secrets.SSH_USER }}
        key: ${{ secrets.SSH_KEY }}
        script: |
          cd /var/www/myapp
          git pull origin main
          npm ci --production
          pm2 restart myapp

Puntos clave:

needs: test asegura que el despliegue solo se ejecute si las pruebas pasan.
La condición if restringe el despliegue a pushes en main.
Los secrets (SSH_HOST, SSH_USER, SSH_KEY) se almacenan en la configuración del repositorio de GitHub y se inyectan de forma segura.

Este patrón funciona para muchos destinos de despliegue: SSH, registros Docker, plataformas cloud (AWS, Vercel, Netlify) o Kubernetes.

Buenas prácticas para CI/CD con GitHub Actions

Mantén los workflows rápidos: Cachea dependencias (p. ej., actions/cache) para reducir los tiempos de compilación.
Falla rápido: Ejecuta comprobaciones rápidas (linting) antes de las pruebas más lentas.
Usa entornos: Configura reglas de protección para despliegues a producción.
Protege los secrets: Nunca hardcodees credenciales; usa GitHub Secrets.
Monitoriza y alerta: Configura notificaciones para workflows fallidos.

Depurando workflows fallidos

Cuando un workflow falla, GitHub muestra los logs de cada step. Los problemas comunes incluyen:

Dependencias faltantes: asegúrate de que npm ci o su equivalente se ejecute antes de las pruebas.
Secrets incorrectos: revisa dos veces los nombres y valores.
Errores de permisos: verifica los permisos del runner y las claves SSH.

También puedes habilitar el registro de depuración configurando el secret del repositorio ACTIONS_STEP_DEBUG a true.

FAQ

¿Cuál es la diferencia entre CI y CD?

CI automatiza las pruebas e integración de los cambios de código. CD automatiza la entrega o despliegue de esos cambios a un entorno. CI asegura la calidad del código; CD asegura que llegue a los usuarios de forma rápida y fiable.

¿GitHub Actions es gratis?

GitHub Actions es gratis para repositorios públicos. Para repositorios privados, obtienes una asignación mensual de minutos gratuitos (p. ej., 2.000 minutos para cuentas Free) y pagas por el uso adicional. Los runners autoalojados también son una opción.

¿Puedo usar GitHub Actions para proyectos que no están en GitHub?

Sí, GitHub Actions puede ejecutar cualquier herramienta de línea de comandos. Puedes usarlo para compilar y desplegar proyectos alojados en otro lugar, siempre que el código esté en GitHub o uses actions para obtenerlo.

¿Listo para optimizar tu CI/CD? Empieza automatizando tus pruebas con GitHub Actions. Para una forma rápida de analizar logs de despliegue, prueba nuestro Nginx Log Analyzer para detectar errores y problemas de rendimiento después de cada despliegue.