CI/CD

Definición

CI/CD son las siglas de Continuous Integration (integración continua) y Continuous Delivery o Continuous Deployment (entrega o despliegue continuo). Son un conjunto de prácticas que automatizan el ciclo desde que un desarrollador hace git push hasta que el código aterriza en producción, pasando por compilación, pruebas, validaciones y despliegue.

La diferencia entre los dos "CD" suele confundir:

• Continuous Delivery: cada cambio queda listo para producción tras pasar pruebas, pero el despliegue final es manual (alguien aprueba el botón).
• Continuous Deployment: cada cambio que pasa todas las pruebas se despliega automáticamente a producción, sin intervención humana.

CI/CD nació para resolver un problema viejo y doloroso: los equipos integraban su código una vez al mes, descubrían entonces miles de conflictos y bugs, y pasaban semanas estabilizando. Hoy, gracias a CI/CD, equipos sanos integran y despliegan varias veces al día sin drama.

Cómo funciona

Un pipeline de CI/CD típico, disparado en cada git push:

1. Trigger: el push a una rama dispara el pipeline (vía webhook a GitHub Actions, GitLab CI, Jenkins, etc.).
2. Build: compila el código, instala dependencias, genera artefactos (binarios, contenedores Docker).
3. Tests: ejecuta tests unitarios, de integración y, opcionalmente, end-to-end.
4. Análisis estático: linter, formateador, escáner de vulnerabilidades (Snyk, Dependabot), análisis de cobertura.
5. Construcción de imagen: empaqueta la app en una imagen versionada (Docker) y la sube a un registro.
6. Despliegue a staging: aplica la imagen al entorno de pruebas, ejecuta smoke tests.
7. Aprobación o despliegue automático a producción: según sea CD entrega o CD despliegue.
8. Verificación post-deploy: monitoriza métricas, errores, latencia. Si algo se dispara, rollback automático.

Cada paso tarda segundos o minutos. Un pipeline bien diseñado lleva un cambio de código a producción en menos de 15 minutos.

Ejemplo práctico

En AE Works mantenemos un proyecto cliente con GitHub Actions. El workflow real, simplificado:

name: Deploy
on:
  push:
    branches: [main]
jobs:
  test-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '22' }
      - run: npm ci
      - run: npm run lint
      - run: npm run typecheck
      - run: npm test
      - run: npm run build
      - name: Deploy a Hostinger
        uses: SamKirkland/FTP-Deploy-Action@v4
        with:
          server: ${{ secrets.FTP_HOST }}
          username: ${{ secrets.FTP_USER }}
          password: ${{ secrets.FTP_PASS }}
          local-dir: ./out/

Cuando un developer hace push a main: lint pasa, tipos validados, tests OK, build genera /out/, FTP-Deploy sube los archivos. Total: 4 minutos. El cliente recibe los cambios sin que toquemos un solo botón.

Tipos de pipelines

• CI puro: solo build + tests. Sin despliegue automático. Útil para librerías o proyectos donde el deploy requiere control manual.
• CI + CD a staging: deploy automático al entorno de pruebas. Producción manual.
• CD completo: deploy automático a producción con feature flags y rollback automatizado.
• Pipelines paralelos: tests, build y análisis corren simultáneamente para acortar tiempos.
• Pipelines con matriz: el mismo test corre en varias versiones de Node, browsers, sistemas operativos.

Herramientas populares

• GitHub Actions: gratis para repos públicos, integración nativa con GitHub. Lo más usado hoy.
• GitLab CI/CD: integrado con GitLab, muy completo, free tier generoso.
• CircleCI: rápido, buen UX, gratuito hasta cierto límite.
• Jenkins: el clásico, autohospedado, infinitamente extensible pero pesado.
• Bitbucket Pipelines: para equipos en Atlassian.
• Vercel / Netlify: CD especializado en frontend, deploy en cada PR con preview URL.

Errores comunes

• Pipelines lentos: si tu CI tarda 40 minutos, los desarrolladores dejan de mirarlo. Paralelizar y cachear es clave.
• Tests inestables (flaky): tests que fallan aleatoriamente erosionan la confianza y se acaban ignorando. Arregla o elimina.
• Secrets en el repositorio: nunca commits credenciales. Usa los gestores de secretos del proveedor.
• Desplegar sin métricas: si despliegas continuamente sin observabilidad (errores, latencia, negocio), te enteras tarde de los desastres.
• No tener rollback: el deploy más seguro es el que sabes deshacer en 30 segundos. Blue/green o canary deployments ayudan.
• CI sin pre-commit local: si solo validas en CI, los desarrolladores rompen main 5 veces al día. Pre-commit hooks bloquean lo evidente antes del push.

Cuándo usarlo

Sí, monta CI/CD desde el primer día cuando:

• El proyecto va a vivir más de unos meses.
• Hay más de un desarrollador (incluido un cliente que revisa).
• Quieres iterar rápido sin romper producción.
• Tu equipo gana tiempo evitando deploys manuales repetitivos.

No, evítalo cuando:

• Es un prototipo de 2 días que no va a producción real.
• Estás en una arquitectura tan exótica que la inversión inicial no compensa.
• No tienes tests significativos aún (en ese caso, primero escribe los tests, luego automatiza).

Referencias

• GitHub Actions Docs — referencia oficial con ejemplos
• Martin Fowler · Continuous Integration — texto clásico sobre la práctica
• The DevOps Handbook — libro de referencia para entender CI/CD en contexto organizativo