Стендап Сьогодні
📢
Канал в Telegram @stendap_sogodni
🦣
@stendap_sogodni@shevtsov.me в Федиверсі
08.08.2025
Хтось повинен стежити за оновленнями
Оновлення залежностей в проєкті — це однозначно непроста задача. Оновлювати кожну, як тільки вийде оновлення — посада на повний робочий день. Не оновлювати зовсім — значить, заганяти себе в ситуацію, коли оновлення стане і невідкладним, і складним — зазвичай з багатьма простроченими взаємозалежностями.
Є ще Dependabot - вбудований у GitHub сервіс відстеження оновлень (або його аналоги.) Він додає третій вибір: оновлювати автоматично версії що мають відомі вразливості. Втім, виходить так, що це не розвʼязує всю задачу, хоча безумовно допомагає швидко помітити та виправити те, що горить.
Отже, я пропоную такий варіант. По-перше, потрібно визначити особу, відповідальну за перевірку оновлень — це може бути інженер підтримки, наприклад. ЇЇ задача — раз на тиждень (чи кілька) переглядати залежності та приймати дії.
Взагалі варто розділяти залежності за ризиками оновлення. Якийсь AWS SDK оновлюється часто, але чудову зворотну сумісність, отже його можна оновлювати хоч кожний тиждень до останньої версії. А ось оновлення Rails - це цілий блок роботи. Якщо мати табличку з класифікацією, не доведеться щоразу наново приймати рішення по кожній окремій залежності.
Це особливо стосується всіляких не дуже важливих пакетів, як-от ті, що використовуються для розробки чи тестів. Бо на них звертають найменше уваги та вони застарівають найчастіше. А можна було б напівавтоматично тримати у свіжості, якщо наперед знати, що це не створює проблем.
Для важливих залежностей можна підписатися на RSS - кожна сторінка релізів на GitHub її має, навіть якщо офіційний сайт проєкту — ні. Я підписаний на все, що хочу тримати свіжим.
Оце якщо для такого підходу є автоматизація, зокрема для моїх улюблених Ruby + JS + Go, то прошу поділитися.