Renovate 44.100: dependencias, PRs y ventana de cambio
Renovate abre PRs de actualización con reglas, horarios y responsables. Cómo usarlo sin romper producción ni perder evidencia de cada cambio.
Un repositorio con 42 dependencias cambia aunque nadie toque el código del negocio. Renovate 44.100.0, publicado el 18 de septiembre de 2026, permite abrir PRs de actualización con reglas, horarios y responsables. Para una pyme, la diferencia visible aparece en el viernes de despliegue: qué paquete cambió, quién lo aprobó y qué prueba bloqueó la salida. Esta guía ordena ese circuito.
Dónde aparece la dependencia que nadie quiere firmar
El dolor aparece en el lockfile, no en una reunión. Un archivo de 11.000 líneas puede cambiar por un parche menor de seguridad, por una versión rota o por una regla de rango demasiado abierta. El antagonista concreto es el PR sorpresa que entra a producción sin una ventana de cambio clara. GitHub informó en Octoverse 2025 que los repositorios públicos pasaron a 395 millones y qué se fusionaron 518,7 millones de pull requests. La cifra muestra el volumen global de cambios pequeños. Renovate sirve cuando ese volumen entra a una organización chica y cada PR necesita dueño, prueba y fecha. El tablero de dependencias baja esa presión a una rutina. Lista paquetes pendientes, separa errores de configuración y deja ver qué actualización espera revisión humana. Para una secretaría administrativa con sistemas chicos, esa vista evita que el proveedor externo llegue el lunes con veinte paquetes mezclados y una sola explicación. La versión 44.100.0 confirma otra idea práctica: la herramienta se mueve rápido. El equipo que la usa debe decidir qué automatiza, qué deja manual y qué bloquea hasta tener evidencia. Una actualización sin dueño es deuda escrita con otro nombre.
Cómo funciona por dentro
El flujo tiene seis pasos. Primero, Renovate lee archivos como package.json, Dockerfile, requirements.txt o composer.json. Recibe nombres de paquetes, rangos de versión y registros de origen. Segundo, consulta fuentes externas y detecta versiones disponibles. Tercero, aplica reglas: agrupar parches, separar majors, respetar horarios y limitar ramas abiertas. Cuarto, abre un branch y un pull request con changelog, diferencias y motivo. Entrega una unidad revisable con cambios visibles. Quinto, el CI corre tests, linters y build de imagen. Si falla, el PR queda bloqueado con el log. Sexto, el dashboard de Renovate muestra pendientes, errores y paquetes ignorados; recibe el estado de cada PR y devuelve una lista de trabajo para sistemas. Los permisos viven en el repositorio. GitHub, GitLab o Forgejo definen quién revisa y quién fusiona. PostgreSQL puede guardar el inventario de repositorios, responsables, ventanas aprobadas y excepciones si la organización ya usa un portal interno. El backup guarda configuración, presets y logs de CI; la restauración se prueba levantando Renovate contra un repo de ensayo y verificando que abre un PR esperado. La configuración inicial conviene escribirla en capas. Un preset común fija horarios, labels y límite de ramas. Cada repositorio agrega excepciones justificadas, por ejemplo mantener una major congelada hasta que soporte valide una migración. Esa separación evita que una regla urgente termine copiada a mano en todos los proyectos.
Qué se instala o configura primero
La primera instalación puede ser el GitHub App oficial o un contenedor self-hosted con token de solo lectura y escritura acotada. En pymes con datos sensibles, conviene empezar self-hosted: un archivo config.js, variables secretas fuera del repo y un runner programado para ejecutarse una o dos veces por día. Con dólar oficial vendedor a $1535, una VM de 2 vCPU y 4 GB para Renovate puede costar entre USD 12 y USD 20 mensuales, unos $18.000 a $31.000 antes de impuestos. Ese costo incluye ejecución programada y logs básicos; deja afuera horas de revisión de PRs y mantenimiento de pipelines. UMSA lo usaría como control de salida, no como botón automático. El primer entregable verificable es chico: tres repositorios, reglas por tipo de cambio, una ventana semanal y un tablero con PRs abiertos, aprobados, fallidos y fusionados. Si el equipo no puede explicar un PR, la regla queda en pausa.
Dónde se rompe y cómo probarlo
El primer riesgo es agrupar cambios incompatibles. La señal aparece cuando un PR mezcla una librería menor con una major. La prueba previa crea dos dependencias de ensayo y verifica que Renovate abra PRs separados por regla. El segundo riesgo es guardar tokens con demasiados permisos. La señal aparece cuando el token puede borrar ramas protegidas o escribir en repositorios fuera del alcance. La prueba usa una cuenta de servicio, intenta tocar un repo no autorizado y confirma rechazo. El tercer riesgo es confiar en tests pobres. La señal aparece cuando el CI aprueba un build que no ejecuta migraciones ni arranque real. La prueba mínima levanta la app con datos de muestra y bloquea el PR si el servicio no responde. El cuarto riesgo es ignorar paquetes archivados o sin mantenimiento. La señal aparece cuando Renovate repite intentos sobre una dependencia que ya no publica parches. La prueba mensual exporta pendientes y marca reemplazo, congelamiento o baja. La salida ordenada es simple: cada paquete actualizado debe traer versión, responsable, prueba y reversa.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.