Actualización automática de dependencias: un pipeline seguro

La mayoría de los equipos trata la actualización automática de dependencias como un bot que se enciende y se olvida, hasta que un lunes el bot abre cuarenta pull requests, la mitad en rojo, y alguien lo apaga. Bien hecha, funciona más como un pequeño pipeline de producción: detecta versiones nuevas, clasifica el riesgo, espera, verifica, fusiona, despliega y puede revertir. Esta guía explica cómo diseñar ese pipeline: el modelo de políticas, las ventajas y desventajas de Dependabot y Renovate, el filtro de CI, el manejo de fallas y los detalles de seguridad que evitan que el actualizador se convierta en una vía de ataque. Si necesitas el lado de negocio (qué debe cubrir un contrato de mantenimiento, quién es responsable de qué), empieza por nuestra guía para armar un plan de mantenimiento de software. Este artículo trata la ingeniería que lo sostiene.

Por qué actualizar dependencias es un problema de sistemas

Cada actualización de una dependencia trae uno de cuatro riesgos distintos, y cada uno pide un control diferente:

• Cambio incompatible. La nueva versión cambia un comportamiento o una API de la que dependes. Control: pruebas y un verificador de tipos que realmente ejerciten la dependencia.
• Versión defectuosa o comprometida. Se publica una versión rota o maliciosa que se retira o corrige poco después. Control: un periodo de espera antes de adoptarla.
• Rezago. Dejas de actualizar durante meses y cada actualización posterior es un salto de varias versiones mayores que nadie quiere revisar. Control: una cadencia constante y programada.
• Fatiga de revisión. Demasiados PR pequeños, así que la gente los aprueba sin mirar o los ignora. Control: agrupación, límites y fusión automática para las clases de bajo riesgo.

Un bot con la configuración por defecto no resuelve bien ninguno de los cuatro. Un pipeline diseñado resuelve los cuatro.

Arquitectura de un pipeline de actualización automática de dependencias

Piénsalo como etapas, cada una con una sola tarea y un modo de falla claro:

1. Detectar. Revisar manifiestos y lockfiles de cada ecosistema (npm, pip, imágenes Docker, GitHub Actions, proveedores de Terraform).
2. Clasificar. Etiquetar cada candidata por tipo de actualización (patch, minor, major, digest), tipo de dependencia (producción o desarrollo) y si corrige una vulnerabilidad conocida.
3. Agrupar. Juntar candidatas relacionadas para que cada PR contenga un cambio coherente.
4. Esperar. Retener las actualizaciones que no son de seguridad hasta que la versión tenga cierta antigüedad mínima.
5. Verificar. Correr CI con una instalación limpia a partir del lockfile actualizado.
6. Decidir. Fusionar automáticamente, pedir revisión o retener, según la política.
7. Desplegar y observar. Publicar por el pipeline normal y vigilar las tasas de error.
8. Recuperar. Revertir rápido, fijar la versión con un motivo y un responsable, abrir un seguimiento.

La decisión clave de diseño: la clasificación y la política viven en configuración versionada, no en la cabeza de las personas. Los revisores solo deberían ver los PR que la política marca como necesitados de un humano.

El modelo de políticas

Antes de elegir herramienta, escribe la política como una lista corta de clases de actualización. Se convierte en tu configuración y en la sección de dependencias de tu runbook de mantenimiento.

• Dependencia de desarrollo, patch o minor: esperar la antigüedad mínima, un grupo semanal, fusión automática con CI en verde.
• Producción, patch: antigüedad mínima, un grupo por ecosistema, fusión automática para paquetes de confianza; si no, revisión.
• Producción, minor: antigüedad mínima, un grupo por ecosistema, revisión humana.
• Cualquier major: antigüedad mínima, un PR por paquete, revisión, y el PR solo se abre tras aprobación explícita.
• Corrección de seguridad: sin espera (o muy corta), PR separado, revisión prioritaria.

El versionado semántico es lo que da sentido a estas clases: según la especificación SemVer, una versión mayor indica cambios incompatibles en la API. Tómalo como una pista, no como una garantía. Muchos paquetes publican cambios incompatibles en versiones minor, por eso "fusión automática" siempre significa "fusión automática si CI pasa", nunca "fusionar a ciegas".

En código, el paso de decisión es una función pura y pequeña, fácil de probar y de explicar en una revisión:

type UpdateType = "patch" | "minor" | "major" | "digest";

interface UpdateCandidate {
  name: string;
  updateType: UpdateType;
  depType: "prod" | "dev";
  releaseAgeHours: number;
  fixesAdvisory: boolean;
}

type Decision = "automerge" | "review" | "hold";

function decide(c: UpdateCandidate, ciGreen: boolean, policy: Policy): Decision {
  if (!ciGreen) return "hold";
  if (c.fixesAdvisory) return "review";                 // vía rápida, pero la revisa un humano
  if (c.releaseAgeHours < policy.minAgeHours) return "hold";
  if (c.updateType === "major") return "review";
  if (c.depType === "dev") return "automerge";
  if (c.updateType === "patch" && policy.trusted.has(c.name)) return "automerge";
  return "review";
}

Rara vez la escribirás tú, porque Dependabot y Renovate implementan versiones de esta lógica, pero tenerla explícita te dice qué opciones de configuración necesitas de verdad.

Dependabot vs Renovate: ventajas y desventajas

Ambas herramientas pueden hacer el trabajo. La diferencia está en cuánto de la política expresa cada una de forma nativa.

Dependabot

Dependabot viene integrado en GitHub, así que no hay nada que alojar. Su opción groups permite consolidar las actualizaciones de varias dependencias en un solo pull request, filtrando por tipo de dependencia y tipo de actualización. Una restricción a tener en cuenta: los grupos se configuran por ecosistema de paquetes. Las actualizaciones de seguridad también se pueden agrupar, lo que ayuda cuando una alerta afecta a varios paquetes.

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 5
    groups:
      prod-minor-patch:
        dependency-type: "production"
        update-types: ["minor", "patch"]
      dev-minor-patch:
        dependency-type: "development"
        update-types: ["minor", "patch"]
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

La fusión automática con Dependabot suele requerir un workflow aparte que lea los metadatos del PR y active el auto-merge de GitHub para las clases permitidas. Funciona, pero la política termina repartida en dos archivos.

Renovate

Renovate puede autoalojarse o usarse como app, y soporta varias plataformas Git, algo importante si no trabajas solo en GitHub. Su gran ventaja para este diseño es que toda la política cabe en un archivo. La opción minimumReleaseAge obliga a Renovate a esperar un tiempo definido antes de sugerir una actualización, y combinada con automerge, Renovate crea el PR de inmediato pero solo lo fusiona cuando pasa ese plazo, añadiendo un check pendiente renovate/stability-days. Dos advertencias de la documentación: la fuente de datos debe ofrecer fechas de publicación para que funcione, y los mantenedores recomiendan definir una antigüedad mínima tanto en Renovate como en tu gestor de paquetes cuando este lo soporte.

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended"],
  "schedule": ["before 6am on monday"],
  "prConcurrentLimit": 5,
  "minimumReleaseAge": "3 days",
  "packageRules": [
    {
      "matchDepTypes": ["devDependencies"],
      "matchUpdateTypes": ["minor", "patch"],
      "groupName": "dev dependencies (non-major)",
      "automerge": true
    },
    {
      "matchUpdateTypes": ["major"],
      "dependencyDashboardApproval": true,
      "labels": ["major-update"]
    }
  ]
}

El valor de "3 days" es un punto de partida que debes ajustar, no un estándar. Esperas más largas atrapan más versiones defectuosas, pero te dejan más tiempo sin las actualizaciones normales. Las correcciones de seguridad deberían quedar exentas o tener una espera mucho más corta.

Regla práctica: un solo repositorio en GitHub con una política sencilla funciona bien con Dependabot. Monorepos, varias plataformas Git o una política con muchas excepciones suelen encajar mejor con Renovate.

El filtro de verificación: que un CI en verde signifique algo

La fusión automática solo es tan segura como el CI del que depende. Para los PR de dependencias, el filtro debería:

• Instalar desde el lockfile, en limpio. Usa npm ci (o pip install --require-hashes, poetry install --sync y similares) para que CI pruebe exactamente lo que se va a publicar.
• Verificar tipos y compilar. Muchos cambios incompatibles en ecosistemas tipados aparecen al compilar, antes de correr cualquier prueba.
• Ejercitar la frontera de integración. Las pruebas unitarias que simulan la dependencia no demuestran nada sobre la versión nueva. Mantén algunas pruebas que usen la librería real: el cliente HTTP, el ORM contra una base de datos desechable, la librería de fechas con zonas horarias.
• Hacer una prueba de humo del artefacto. Levanta el contenedor compilado y consulta un endpoint de salud más una o dos rutas críticas.
• Fallar ante pruebas inestables, no reintentar hasta que pasen. Si las pruebas inestables se reintentan hasta salir en verde, la fusión automática terminará publicando una regresión real. Pon en cuarentena las pruebas inestables de forma explícita y dales seguimiento.

name: ci
on: pull_request
permissions:
  contents: read
jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<pinned-commit-sha>
      - uses: actions/setup-node@<pinned-commit-sha>
        with:
          node-version-file: ".nvmrc"
      - run: npm ci
      - run: npm run typecheck
      - run: npm test -- --ci
      - run: npm run build
      - run: ./scripts/smoke-test.sh

Manejo de fallas: qué pasa cuando una actualización rompe producción

Planéalo, porque va a pasar. Tu diseño necesita tres cosas.

Una reversión en un paso. Cada cambio de dependencias entra como su propio merge commit o squash, para que revertirlo no arrastre trabajo ajeno. Es otra razón para no mezclar actualizaciones de dependencias con PR de funcionalidades.

Versiones fijadas con motivo y responsable. Cuando retengas un paquete, registra por qué y qué lo desbloquea, junto a la regla:

{
  "matchPackageNames": ["some-orm"],
  "allowedVersions": "<5.0.0",
  "description": "Fijado: v5 cambia la API de transacciones. Responsable: equipo backend. Revisar al cerrar el ticket de migración."
}

Las versiones fijadas sin responsable se convierten en el rezago que intentabas evitar. Revísalas con la misma cadencia que el resto del trabajo de mantenimiento.

Observación al desplegar. Etiqueta los despliegues que solo contienen cambios de dependencias para que, cuando las tasas de error se muevan, el tablero señale la causa de inmediato.

Seguridad: que el actualizador no se convierta en la vía de ataque

Un pipeline automatizado que fusiona código de terceros es, por definición, un punto de entrada a la cadena de suministro. Endurécelo:

• Tokens de CI con privilegios mínimos. Declara permissions: de forma explícita y da acceso de solo lectura a los workflows de PR de dependencias, salvo que un paso realmente necesite más.
• Nada de secretos de producción en los builds de PR. Los scripts de instalación de una versión nueva se ejecutan dentro de tu CI. No dejes que vean llaves de despliegue.
• Fija actions e imágenes base por digest o SHA de commit, y deja que el actualizador suba esas referencias. Obtienes reproducibilidad y actualizaciones sin etiquetas flotantes.
• Versiona los lockfiles y haz fallar CI si no coinciden con el manifiesto.
• Exige revisión para todo lo que cambie el propio pipeline: workflows de CI, configuración del actualizador, Dockerfiles. Usa code owners para que la fusión automática nunca cubra esas rutas.

Rendimiento: mantener la cola corta

Un pipeline sano tiene una cola corta. Limita los PR simultáneos (open-pull-requests-limit en Dependabot, prConcurrentLimit en Renovate), programa las ejecuciones que no son de seguridad en una ventana fija para que no compitan con el trabajo de producto toda la semana, y agrupa sin miedo las clases de bajo riesgo. Si las versiones mayores se acumulan, dales un espacio fijo en el sprint. Una versión mayor ignorada durante un año suele convertirse en un proyecto.

Checklist

• Política escrita y versionada en el repositorio
• Todos los ecosistemas cubiertos, incluidos actions de CI, imágenes de contenedor y proveedores de infraestructura
• Clases de bajo riesgo agrupadas, versiones mayores por separado
• Antigüedad mínima definida para actualizaciones normales, seguridad exenta
• CI instala desde el lockfile, verifica tipos, compila y hace pruebas de humo
• Pruebas de integración con la librería real, no con simulaciones
• Fusión automática limitada a las clases que permite la política, nunca sobre CI ni la configuración del actualizador
• Tokens de CI con privilegios mínimos, sin secretos de despliegue en builds de PR
• Actions e imágenes fijadas por SHA o digest
• Cada versión fijada tiene motivo, responsable y fecha de revisión
• Despliegues de solo dependencias etiquetados en el monitoreo

Errores comunes

• Encender el bot con la configuración por defecto en un repositorio grande. Recibes una avalancha de PR y un equipo que aprende a ignorarlos. Empieza con agrupación y límites.
• Fusionar automáticamente con un CI débil. Si tus pruebas no tocan la dependencia, el verde no significa nada.
• Ignorar los ecosistemas que no son de la aplicación. Las actions de CI y las imágenes base desactualizadas también son dependencias.
• Hacer esperar a las correcciones de seguridad como a todo lo demás. La espera por antigüedad es para actualizaciones de rutina. Las alertas de seguridad necesitan un carril rápido.
• Versiones fijadas para siempre. Una versión fijada sin responsable ni condición de salida es deuda que solo crece.

Si tu equipo heredó un código con años de atraso en dependencias, ponerse al día suele ser un proyecto propio antes de que cualquier automatización rinda. Es el tipo de trabajo que hacemos en nuestros proyectos de desarrollo y mantenimiento de software a la medida.

Preguntas frecuentes

¿Debo fusionar automáticamente las actualizaciones de dependencias de producción?

Solo para las clases que tu política marque como de bajo riesgo, normalmente actualizaciones patch de paquetes de confianza, y solo si CI ejercita la librería real. Las versiones minor y major en código de producción deberían pasar por revisión humana.

¿Cuánto debe durar la antigüedad mínima de una versión?

No hay un número universal. Es un equilibrio entre atrapar versiones defectuosas y mantenerse al día. Empieza con unos pocos días para las actualizaciones de rutina, exenta las correcciones de seguridad y ajusta según lo que observe tu equipo.

¿Dependabot o Renovate?

Dependabot si estás en GitHub con una política sencilla y no quieres alojar nada. Renovate si necesitas varias plataformas Git, soporte para monorepos o una política detallada expresada en un solo archivo.