Як організувати автоматичне оновлення залежностей у великому проєкті: Renovate, групування, автозлиття?

У великому проєкті з десятками залежностей бот, що відкриває окремий PR на кожне оновлення, швидко стає шумом, який команда ігнорує. Мета - щоб рутинні оновлення проходили без людей, а увагу отримували лише ризиковані.

Renovate - гнучкіша альтернатива Dependabot: підтримує більше екосистем, складні правила, групування, автозлиття й «панель залежностей» (Dependency Dashboard) - задачу зі списком усіх очікуваних оновлень.

{
    "extends": ["config:recommended"],
    "schedule": ["before 6am on monday"],
    "minimumReleaseAge": "3 days",
    "lockFileMaintenance": { "enabled": true },
    "packageRules": [
        {
            "matchUpdateTypes": ["patch", "minor"],
            "matchCurrentVersion": "!/^0/",
            "automerge": true
        },
        {
            "matchPackageNames": ["laravel/**", "livewire/**", "filament/**"],
            "groupName": "Laravel ecosystem"
        },
        {
            "matchDepTypes": ["require-dev"],
            "groupName": "dev dependencies",
            "automerge": true
        },
        {
            "matchUpdateTypes": ["major"],
            "dependencyDashboardApproval": true
        }
    ]
}

Що тут відбувається:

• автозлиття патчів і мінорних версій стабільних пакетів - якщо CI зелений, PR вливається сам;
• групи - пов'язані пакети оновлюються разом (екосистема Laravel), а не десятком окремих PR;
• мажорні версії - лише після схвалення на панелі, бо вони потребують міграції коду;
• minimumReleaseAge - не брати версію, опубліковану щойно: зламані й скомпрометовані релізи зазвичай відкликають за перші дні;
• lockFileMaintenance - періодично оновлює транзитивні залежності в composer.lock, які інакше застарівають непомітно;
• розклад - PR з'являються в певний час, а не протягом усього тижня.

Передумови для автозлиття:

• тести, яким можна довіряти - інакше автозлиття постачає баги в main;
• обов'язкові перевірки в захисті гілки - бот не повинен мати змоги злити червоний PR;
• моніторинг після деплою - швидко помітити регресію й відкотити.

Dependabot чи Renovate: Dependabot вбудований у GitHub і простіший у налаштуванні (групи, cooldown, ігнорування є й у ньому); Renovate виграє на складних правилах, монорепозиторіях і поза GitHub (GitLab, Bitbucket).

Докладніше в документації: Renovate: параметри конфігурації