EMZETT.
Увійти

Автоматичні оновлення залежностей: Dependabot і Renovate

Коротко: Dependabot і Renovate регулярно перевіряють, чи немає в бібліотек нових версій або патчів безпеки, й автоматично відкривають pull request з оновленням.

Докладніше: Сучасні проєкти залежать від сотень пакетів. Якщо вони застарівають, накопичуються вразливості та дорогі стрибки версій. Ручну перевірку забувають; боти беруть її на себе регулярно й невеликими кроками.

Подробиці

Як це працює

Бот читає package.json/lock-файли, requirements.txt, pom.xml, Dockerfile, файли GitHub Actions і порівнює з останніми версіями. Якщо є оновлення, він створює pull request зі списком змін, посиланням на нотатки про випуск і прогоняє ваші CI-тести. Ви перевіряєте й зливаєте. Про вразливості (CVE) повідомляють сповіщення безпеки Dependabot і створюють термінові PR.

Dependabot і Renovate

  • Dependabot (GitHub): простий, конфігурація .github/dependabot.yml; інтегрований у функції безпеки GitHub.
version: 2
updates:
  - package-ecosystem: npm
    directory: "/"
    schedule: { interval: weekly }
    groups:
      dev-tools: { dependency-type: development }
  • Renovate (відкритий код, також GitLab, Gitea, можна розгорнути у себе): дуже гнучко налаштовується (групування, автозлиття патчів, правила за пакетами, часові вікна), підтримує багато форматів.

Обидва найкраще працюють із хорошим набором тестів.

Хороша практика

  • Групуйте (наприклад, усі інструменти розробки в одному PR), щоб не було потоку PR.
  • Автоматично зливайте патч- і мінорні оновлення за зелених тестів, мажорні оновлення перевіряйте вручну.
  • Версіонуйте lock-файли, щоб збірки були відтворюваними.
  • Читайте нотатки про випуск, особливо для мажорних версій і несумісних змін.
  • Фіксуйте критичні залежності (діапазони версій, ~/^, обирайте свідомо).
  • Розклад (щотижня) замість щоденної метушні.
  • Враховуйте ланцюжок постачання: оновлення теж можуть бути шкідливими (скомпрометовані пакети); запроваджуйте нові версії з коротким періодом очікування (наприклад, 3 дні).

Користь

Менше ризику безпеки, менші оновлення (простіше налагоджувати, ніж стрибок через 2 роки), актуальні інструменти і менше «боргу за оновленнями». Для невеликих проєктів достатньо щомісячної перевірки за допомогою npm outdated/npm audit/pip list --outdated, якщо зусилля на бота здаються завеликими.

Див. також: Залежності та вразливості (CVE), npm audit, Ланцюжок постачання ПЗ