Publicado en

CI/CD: qué es la integración y entrega continua

por Yassin A.••Publicado enDevOps y Herramientas
Fragmento de un workflow de GitHub Actions con triggers, jobs y steps sobre fondo oscuro

Tienes el código listo. Hay que subirlo a producción. El proceso habitual: conectarte al servidor, hacer pull, reiniciar el servicio, esperar, verificar. Si algo falla, repetir. Si hay varios entornos, multiplicar. CI/CD automatiza todo eso y añade algo más importante: garantiza que el código que llega a producción ha pasado los tests.

Qué es CI/CD

Son dos prácticas que se complementan:

  • CI (Continuous Integration — Integración Continua): cada vez que un desarrollador hace push al repositorio, el sistema automáticamente compila el código y ejecuta los tests. Si algo falla, el pipeline se detiene y nadie puede fusionar código roto.
  • CD (Continuous Delivery/Deployment — Entrega/Despliegue Continuo): si el código pasa la CI, se despliega automáticamente a un entorno (staging primero, producción después si se configura así).

El pipeline paso a paso

El pipeline CI/CD completo: Commit, Build, Test, Staging y Producción con la diferencia entre CI y CD marcada

Un pipeline típico sigue esta secuencia: el desarrollador hace commit y push → el sistema detecta el evento → arranca el pipeline → compila el código → ejecuta los tests → si todo pasa, despliega a staging → opcionalmente despliega a producción.

Lo fundamental es que si cualquier paso falla, el pipeline se detiene. El código no llega a producción. El desarrollador recibe una notificación. La rama main siempre está en estado desplegable.

GitHub Actions

Anatomía de un workflow de GitHub Actions con los conceptos de on, jobs, runs-on, steps, uses y run explicados

GitHub Actions es la herramienta de CI/CD integrada en GitHub. Los workflows se definen como archivos YAML en .github/workflows/. Cuando ocurre un evento (push, pull request, etc.) GitHub arranca el workflow en una máquina virtual limpia.

name: CI

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

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout código
        uses: actions/checkout@v4

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

      - name: Instalar dependencias
        run: npm ci

      - name: Ejecutar tests
        run: npm test

      - name: Build
        run: npm run build

Este workflow se ejecuta en cada push a main o develop, y en cada pull request. Instala Node, instala dependencias, pasa los tests y construye el proyecto. Si cualquier paso devuelve un código de salida distinto de cero, el workflow falla.

Añadir despliegue automático

  deploy:
    runs-on: ubuntu-latest
    needs: test           # solo se ejecuta si el job test pasa
    if: github.ref == 'refs/heads/main'  # solo desde main

    steps:
      - uses: actions/checkout@v4

      - name: Deploy a producción
        run: |
          ssh -o StrictHostKeyChecking=no ${{ secrets.SERVER_USER }}@${{ secrets.SERVER_HOST }} \
            "cd /app && git pull && npm install && pm2 restart app"
        env:
          SSH_KEY: ${{ secrets.SSH_PRIVATE_KEY }}

Los secretos (tokens, contraseñas, claves SSH) se guardan en Settings → Secrets del repositorio y se inyectan como variables de entorno. Nunca aparecen en el código ni en los logs.

Herramientas alternativas

GitHub Actions es la opción más directa si usas GitHub, pero el ecosistema es amplio. GitLab CI/CD funciona igual de bien si el repositorio está en GitLab, con una configuración similar en .gitlab-ci.yml. Jenkins es la opción on-premise más establecida, más configurable pero más compleja de mantener. CircleCI y Bitbucket Pipelines son alternativas según dónde esté el código.

Con el código probado, construido y desplegado automáticamente, el siguiente eslabón es el acceso remoto a los servidores donde todo eso corre: conectarse de forma segura, transferir archivos y gestionar el sistema sin exponer contraseñas en texto plano.