Як оновлювати бібліотеки сторонніх розробників?

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

Це, очевидно, занадто багато. Навіть незважаючи на те, що версія 1.2.3 зазвичай є заміною для версії 1.2.2, без тестування ви ніколи не знаєте . Одиничних тестів недостатньо; якщо це DB / file engine, ви повинні переконатися, що він працює належним чином з файлами, створеними з більш старими версіями, а може бути і навпаки. Якщо це має щось спільне з GUI, ви повинні візуально все перевірити. І так далі.

Як ви справляєтеся з цим? Деякі можливі підходи:

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

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

Я не купую цю думку, що зміни бібліотеки якось складніше перевірити, ніж зміни коду. Це точно так само - ви вносите зміни в базу коду, і вам потрібно перевірити її перед тим, як зробити їх, і більш глибоко перед випуском. Але для цього ви вже повинні мати процеси, оскільки ви вносите зміни коду!

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

Тепер питання полягає в тому, що ви робите, якщо оновлення порушує речі - чи витрачаєте ви час на їх виправлення, чи залишаєте його? Я б запропонував схилитися до останнього; якщо це можна буде виправити за годину, зробіть це, але якщо оновлення потребує значної роботи для інтеграції, тоді підніміть його як своє власне завдання розвитку, яке буде оцінено, встановлено пріоритетність та заплановано так само, як і будь-яке інше. Шанси полягають у тому, що, якщо це не призведе до надзвичайно важливих виправлень або покращення, пріоритет буде низьким, і ви його ніколи не обійдете. Але ніколи не знаєш, до моменту, коли наступне ітераційне оновлення дня прокручується, проблема, можливо, сама по собі виправиться; навіть якщо ні, то, принаймні, тепер ви знаєте, що на шляху оновлення є блокпост, і це не застане вас зненацька.

Якщо ви не робите ітерацій такої тривалості, я б створив якийсь окремий графік оновлень - не довше щомісяця. Чи є якийсь інший ритм проекту, з яким ви могли би його пов’язати, наприклад, щомісячний огляд статусу чи засідання ради архітектури? День оплати? Ніч піци? Повний місяць? Як би там не було, вам потрібно знайти щось набагато коротший, ніж традиційний цикл випуску, адже намагання оновлювати все за один раз кожні 6-18 місяців буде болісним і деморалізуючим.

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

Я оцінюю.

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

Потім я зважую все це на те, щоб не залишатися з існуючою мовою.

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

Основна проблема, що стосується сторонніх бібліотек, полягає в тому, що вам потрібно повторно перевірити ВАШЕ додаток під час оновлення, перш ніж воно може розпочати виробництво. Тож якщо у вас немає повідомленої помилки, яка потребує оновлення бібліотеки, ви не торкаєтесь їх, поки у вас є час пройти повний цикл забезпечення якості.

Зазвичай це робиться при випуску нової версії.

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

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

Я б подумав про оновлення всіх бібліотек проекту безпосередньо перед випуском або безпосередньо після нього. Це, однак, може вийти з ладу, якщо ви покладаєтесь на більше 10 або 15 бібліотек, і в цьому випадку якийсь механізм перевірки оновлення значно допоможе. Перевагою цього є те, що ви приділяєте час тестуванню своїх бібліотек і можете вирішити будь-які проблеми за один прохід. Вам також не потрібно постійно слідкувати за оновленнями з кожної бібліотеки, ви просто перевіряєте в певний день наявність оновлень.

Я б також заперечував проти будь-якої функції автоматичного оновлення навіть у відділенні розробників. Було б сумно, якби в середині мене працювали над тим, що проект зламався, оскільки бібліотека автоматично оновилася, або я раптом отримав попередження про амортизацію щодо використання API, який просто замінив щось інше.

Ви повинні запитати, що ви насправді хочете оновлювати? Більшість виправлень безпеки - це фактично тривіальні виправлення у вигляді виправлення:

• Вимкнено однією помилкою, коли довільний код можна скопіювати у невикористаний простір у буфері
• Невизначені покажчики чи щось інше, що викликає не визначене, але (скоріше) детерміновану поведінку
• Помилки, які дозволяють отримати якусь DoS
• Помилки, які випадково спрощують перегляд приватних даних
• Математичні помилки
• Обслуговувачі торкаються речей, які вони не повинні (помилка Debian SSL, хтось?)

Якщо ви переглядаєте більшість CVE за останні п’ять років, патчі, які їх виправляють, як правило, досить тривіальні, якщо ви використовуєте відкриті бібліотеки, які, я сподіваюся, є.

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

Нарешті, у вас є нові функції .. і, можливо, застарілі функції. Вам потрібно вивчити ці нотатки до випуску та відрізняти їх уважно. Чи можете ви їх використовувати, навіть якщо вони порушують API, від якого залежить багато інших речей? Якщо так, то час для операції. Якщо ні, вишня виберіть те, що вам потрібно, і рухайтеся далі.

Деякі можуть погодитися зі мною, але я відмовляюся використовувати бібліотеку без вихідного коду.

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

В ідеалі ви завжди мали б останню версію, але якщо нова версія не сумісна із зворотнім, що тоді? Можливо, вам доведеться відкласти це оновлення для майбутнього випуску, поки ви не зможете обережно впоратися зі зміною. Можливо, відбудеться деяка тонка зміна в поведінці (наприклад, "вам зараз потрібно встановити властивість X перед тим, як викликати метод Y, або ви отримаєте повільний витік пам'яті"), що важко перевірити при тестуванні.

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

Коротка версія: прийміть її в кожному конкретному випадку.

Це залежатиме від графіку випуску.

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

Лише після того, як випуск буде розгорнуто, і ви перебуваєте на етапі після випуску, перегляньте свої бібліотеки, їх версії та функції. Якщо вони пропонують якісь значні вдосконалення чи нові функції, то встановіть їх до початку наступного циклу розробки.

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

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

Підривна зовнішність

У цій функції чудово, що ви можете вказати потрібну редакцію.

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

Я зараз налаштовую щось подібне:

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

Тепер, коли мені потрібно працювати над розширенням, яке не є "базовим" (явно включене як субрепо в репортаж програми), я просто клоную репо в папку розширень і дозволю CMake генерувати проекти та рішення для всієї програми.

Таким чином я можу:

• змінити третіх сторін у клоні, переконатися, що він працює з додатком, натиснути його на 3-е парне репо, а потім оновити субрепо версію програми repo до нової версії третьої репо-версії.
• працюйте над розширеннями самостійно, всі togeter або просто виберіть якусь конкретну
• не потрібно турбуватися про те, що потрібно зв’язувати проекти разом, це робиться Cmake лише шляхом того, щоб проекти підпропозицій були скановані з усім репо-додатком.

У вас ще немає великого досвіду роботи з цією організацією, але я думаю, що це досить корисно.

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

В іншому випадку, коли губка дозріла, це "Якщо вона не зламалася, не виправляйте". для мене. Рано чи пізно мені може знадобитися функція пізнішої версії, і не залишається нічого іншого, як оновлювати, але до цього часу зусилля важко виправдати. З іншого боку, коли я працюю з відносно новою версією або рамкою, як Grails або ExtJS, я завжди в курсі останньої версії, оскільки ці продукти ще не відчувають себе повністю зрілою, тому оновлення, ймовірно, врятує мене від попадання в одну з цих помилок, виправлена ​​пізніша версія.

Я використовую NuGet для того, щоб постійно оновлювати бібліотеки своїх третіх сторін.

Коли друг, співробітник або блог повідомляє мене про те, що одна з моїх сторонніх DLL-програм застаріла, NuGet дозволяє дуже легко її оновити.