Коли слід оновлювати залежності?

У нас було два основні кризи, пов'язані із залежністю, з двома різними базами коду (Android та веб-додаток Node.js). Android Repo потребував переходу від шквалу до Firebase, що вимагало оновлення бібліотеки Служб Google Play чотирьох основних версій. Аналогічна ситуація трапилася і з нашим додатком Node, розміщеним у Heroku, де наш виробничий стек (кедр) був застарілим і його потрібно було оновити до кедра-14. Нашій базі даних PostgreSQL також потрібно було оновити з 9,2 до 9,6.

Залежності кожної з цих програм майже два роки простояли, і коли деякі були застарілими, і ми досягли періоду «заходу сонця», головним болем було їх оновити або замінити. Я витратив понад 30 годин за останній місяць-два, щоб повільно вирішувати всі конфлікти та зламаний код.

Очевидно, що залишати речі сидіти два роки - це занадто довго. Технологія швидко рухається, особливо коли ви користуєтеся платформою, наприклад Heroku. Припустимо, що у нас є повноцінний тестовий набір та такий процес CI, як Travis CI, який вимагає багато здогадок з оновлення. Наприклад, якщо функцію було видалено після оновлення, і ви її використовували, ваші тести не зможуть.

Як часто слід оновлювати залежності чи коли слід оновлювати залежності? Ми оновлювались, тому що нас змушували, але, схоже, якийсь превентивний підхід був би кращим. Чи слід оновлювати, коли виходять незначні версії? Основні версії? Щомісяця, якщо оновлення доступні? Я хочу уникнути такої ситуації, як те, що я щойно пережив, будь-якою ціною.

PS - для одного з моїх персональних проектів Rails я використовую послугу під назвою Gemnasium, яка відстежує ваші залежності, щоб вас могли отримувати повідомлення, наприклад, про вразливості безпеки. Це чудовий сервіс, але нам доведеться вручну перевіряти залежності для згаданих мною проектів.

Як правило, слід оновити залежності, коли:

1. Це потрібно
2. Для цього є перевага
3. Не робити цього невигідно

(Вони не є взаємовиключними.)

Мотивація 1 ("коли треба") - найневідкладніший рушій. Деякий компонент або платформа, від якої ти залежиш (наприклад, Heroku) вимагає цього, і ти повинен впасти в ряд. Необхідні оновлення часто каскадують з інших варіантів; ви вирішили оновити до версії PostgreSQL так собі. Тепер вам доведеться оновити драйвери, версію ORM тощо.

Модернізація, оскільки ви чи ваша команда сприймає перевагу в цьому, є більш м'яким та необов’язковим. Більше заклику до судового рішення: "Невже нова особливість, здатність, продуктивність ... вартує зусиль та дислокації, яка приводить її до себе? У Olden Times існував сильний ухил від необов'язкових оновлень. Вони були ручними і важкими, не було гарних способів спробувати їх у пісочниціабо віртуальне середовище, або повернути оновлення назад, якщо воно не вийшло, і не було швидких автоматизованих тестів, щоб підтвердити, що оновлення не «засмутили візок яблук». У наш час упередженість спрямована на набагато швидші та агресивніші цикли оновлення. Спритні методи люблять пробувати речі; автоматизовані інсталятори, менеджери залежностей та repos роблять процес установки швидким і часто майже непомітним; віртуальне середовище та всюдисущий контроль над версіями полегшують гілки, вилки та зворотній зв'язок; і автоматичне тестування давайте спробуємо оновити, а потім легко і суттєво оцінити "Це спрацювало? Чи щось викрутило?" Ухил змістився оптом: від "якщо він не зламався, не виправляйте його" до "оновлення рано, оновлення часто"

Мотивація 3 - найм'якша. Історії користувачів не стосуються себе "сантехніки" і ніколи не згадують "і зберігають інфраструктуру не більше ніж N випусків за поточною". Недоліки дрейфу версії (приблизно, технічна заборгованість, пов’язана з падінням за кривою) зазіхають безшумно, а потім часто заявляють про себе через поломку. "Вибачте, що API більше не підтримується!" Навіть в колективах Agile може бути важко мотивувати інкременталізм і «залишатися на вершині» свіжості компонентів, коли це не сприймається як головне для завершення заданого спринту або випуску. Якщо ніхто не виступає за оновлення, вони можуть залишатися без уваги. Це колесо може не скрипіти, поки воно не буде готове зламатись, або навіть поки не зламається.

З практичної точки зору, вашій команді потрібно приділяти більше уваги проблемі дрейфу версії. 2 роки занадто довгі. Магії немає. Це лише питання "плати мені зараз або плати мені пізніше". Або вирішуйте проблему з дрейфом версії поступово, або страждайте, а потім кожні кілька років переживайте більші поштовхи. Я віддаю перевагу інкременталізму, тому що деякі потрясіння платформи величезні. Ключовий API або платформа, від якої ви більше не працюєте, може дійсно зруйнувати ваш день, тиждень або місяць. Мені подобається оцінювати свіжість компонентів принаймні 1-2 рази на рік. Ви можете чітко планувати огляди або дозволяти органічно спрацьовувати відносно метрономічним, зазвичай щорічним циклом оновлення основних компонентів, таких як Python, PostgreSQL та node.js. Якщо оновлення компонентів не викликає вашої команди дуже сильно, свіжість перевіряє основні випуски, на плато природних проектів або кожен k випуск також може працювати. Що б не звертало увагу на виправлення дрейфу версії на більш регулярній каденції.

Бібліотеки слід оновлювати, коли їх потрібно оновлювати. Це означає, що якщо оновлення не приносить значення, ви не повинні.

У вашому конкретному випадку ви переходили зі старого технологічного стека на новий, і для цього ви змушені були оновити свої залежності. Саме цей момент - правильний час для оновлення залежностей.

Якби ви оновляли залежність протягом часу, щоб "не боліти голова зараз", вам довелося б вкласти багато робочого часу (кодування), щоб не повернути значення. І коли ви повинні були зробити останнє оновлення (те, що ви робите зараз, але оновлення 1 основної версії замість 4), ви, ймовірно, десь будуть боліти головою (адже, основна версія означає порушення змін). Тож я думаю, що ти на вірному шляху.

Однак, якщо вам важко мігрувати, і вам доведеться зробити багато рефактора, швидше за все, проблема полягає у вашій кодовій базі даних. Досить часто для проектів Android не має загальної архітектури з точки зору структури коду. Хороша структура введення залежності, як Dagger 2 , і кілька принципів інженерії програмного забезпечення, таких як SOLID , полегшили б змінити реалізацію коду, зберігаючи ту саму поведінку / вимоги.

Крім того, оскільки ми займаємось рефакторингом, прочитайте трохи про тестування одиниць, оскільки це дуже допоможе при виконанні подібних робіт.

Якщо ви користуєтеся інструментами управління пакетами (наприклад, npm, NuGet) і маєте комплексний автоматизований тестовий набір, то оновлення залежностей повинно бути невисоким зусиллям, просто оновіть пакет, запустіть тестовий набір і перевірте, чи є проблеми. Якщо тоді є відкат, підніміть робочий предмет для розслідування та усунення проблеми.

Поки вартість модернізації залежних низька, її варто оновлювати:

• Якщо виникають проблеми з оновленням, ви хочете дізнатися це швидше, ніж пізніше, якщо потрібні зміни в потоці.
• Залишаючи оновлення залежності до останньої хвилини, часто означає, що ви робите ці оновлення під час стиснення (наприклад, у відповідь на критичну помилку щодо безпеки). Тримаючи верх над своїми залежностями означає, що ви контролюєте, коли витрачаєте ці зусилля, і можете виконувати ці оновлення у той час, коли ви не так зайняті.
• Новіші версії можуть покращити продуктивність, наприклад, краща документація, простіший у використанні API, виправлення помилок (хоча зворотний також можливий).

Якщо оновлення залежностей не є малим зусиллям (наприклад, тому, що вам потрібно вручну протестувати оновлення або тому, що є відомі проблеми / неполадки змін), вам доведеться зважити плюси та мінуси щодо інших ваших завдань. Старі залежності - це вид технічної заборгованості з низькими відсотками, і до цього слід ставитися відповідно.

Не слід робити випуск, коли ви свідомо використовуєте старі версії своїх залежностей, якщо тільки ці версії не підтримують альтернативи.

тобто якщо ви перебуваєте на V1 і він все ще підтримується, ви все одно можете використовувати останню версію v1.

Ви можете застаріти, якщо:

A: Ви не робили реліз протягом певного часу.

B: Ви так довго перебуваєте на v1, що він більше не підтримується

Оновлення випускаються з причини, вони містять виправлення безпеки, які слід брати на борт.

Якщо вийде нова версія вашої залежності, вам також слід робити реліз

Я думаю, що це певною мірою залежить від бібліотеки, однак у мене були подібні головні болі залежностей.

Здоровий глузд каже мені, що основна версія, мабуть, є правильним часом для оновлення, а незначна версія, яка вирішує серйозний недолік або містить значну вигоду, це замінить.

Іноді ми не маємо розкоші працювати над кожною програмою, яка потребує технічного обслуговування або навіть нерозбірливого завдання, але вони зрештою вас вкусять, і унція профілактики часто долає півлітра вилікування!

Бібліотеки слід оновлювати, коли пропонується перевага, яке використовуватиме ваше програмне забезпечення, яке компенсує витрачену роботу на зміну.

Навіть незначні оновлення версій бібліотеки можуть порушити або вставити невідповідності в додатках. З цього погляду незначних змін немає.

Немає сорому у використанні старих губ. Коли потрібні зміни, можуть бути болісними, але це частина роботи.