Как вы решаете, когда обновить библиотеку в вашем проекте?

Question

Я работаю над проектом, который использует несколько библиотек Java с открытым исходным кодом. Когда выходят обновления для этих библиотек, мы склонны следовать консервативной стратегии:

1. если он не сломался, не чините
2. если у него нет новых функций, которые мы хотим, игнорируйте его

Мы придерживаемся этой стратегии, потому что обычно у нас нет времени, чтобы вставить новую библиотеку и тщательно протестировать приложение в целом. (Как и многие команды разработчиков программного обеспечения, мы всегда отставали от запланированных функций, которые мы обещали несколько месяцев назад.)

Но я иногда задаюсь вопросом, разумна ли эта стратегия, учитывая, что некоторые улучшения производительности и большое количество исправлений ошибок обычно идут с обновлениями библиотеки. (т.е. "Кто знает, может быть, все будет работать лучше, чем мы не предвидим ...")

Какие критерии вы используете, когда принимаете подобные решения в своем проекте?

Answer 1

Важно: избегать технических долгов .

«Если ничего не сломано, не обновляйте» - это сумасшедшая политика, которая приводит к такому взлому программного обеспечения, что никто не может его починить.

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

Запустите процесс "ночной сборки", чтобы вы могли непрерывно тестировать все изменения - как ваши, так и пакеты, от которых вы зависите.

Пока у вас нет непрерывного процесса интеграции, вы можете выпускать ежеквартальные основные выпуски, которые включают обновления инфраструктуры.

Избегайте технических долгов.

Answer 2

Я выучил достаточно уроков, чтобы сделать следующее:

1. Проверьте список изменений библиотеки. Что они исправили? Меня это волнует? Если список изменений отсутствует, библиотека не используется в моем проекте.
2. О чем люди пишут на форуме библиотеки? Вскоре после релиза появилось множество сообщений, указывающих на очевидные проблемы?
3. В том же духе, что и номер 2, не обновляйте сразу. У ВСЕХ плохой релиз. Я не собираюсь быть первым, кто получит эту маленькую ошибку. (больше так и есть). Это тоже не значит ждать 6 месяцев. В течение первого месяца выпуска вы должны знать недостатки.
4. Когда я решу продолжить апгрейд; тест, тест тест. Здесь автоматизированное тестирование чрезвычайно важно.

РЕДАКТИРОВАТЬ: Я хотел добавить еще один элемент, который, по крайней мере, так же важен, и, возможно, больше, чем другие.

• Какие критические изменения были внесены в этот выпуск? Другими словами, библиотека движется в другом направлении? Если библиотека устарела или заменяет функциональность, вам стоит остановиться на этом.

Answer 3

Я предпочитаю не позволять версиям слишком сильно отставать от зависимых библиотек. Для большинства библиотек это год, если не известны проблемы безопасности или производительности. Библиотеки с известными проблемами безопасности являются обязательными для обновления.

Я периодически загружаю последнюю версию каждой библиотеки и запускаю модульные тесты своих приложений, используя их. Если они проходят, я использую их в наших средах разработки и интеграции некоторое время и подталкиваю к QA, когда я удовлетворен, что они не отстой.

Приведенная выше процедура предполагает, что API существенно не изменился. Все ставки отключены, если мне нужно провести рефакторинг существующего кода, чтобы использовать более новую версию библиотеки. (например, Ось 1х против 2х) Тогда мне нужно было бы привлечь руководство, чтобы принять решение о распределении ресурсов. Такое изменение, как правило, будет отличаться до тех пор, пока не планируется крупный пересмотр устаревшего кода.

Answer 4

Я обычно предполагаю, что игнорирование новой версии библиотеки (потому что она не имеет каких-либо интересных функций или улучшений) является ошибкой, потому что однажды вы обнаружите, что эта версия необходима для перехода на следующая версия, которую вы можете обновить до.

Поэтому я советую внимательно изучить то, что изменилось в новой версии, и подумать, требует ли эти изменения большого тестирования или небольшого.

Если требуется много тестирования, лучше всего перейти на более новую библиотеку в следующем выпуске (основной версии) вашего программного обеспечения (например, при переходе с v8.0 на v8.5). Когда это произойдет, я полагаю, что есть и другие важные модификации, поэтому проведено много испытаний.

Answer 5

Несмотря на то, что вы не хотите обновлять только потому, что есть новая версия, есть еще одно соображение, а именно наличие старой версии. Я столкнулся с этой проблемой, пытаясь создать проекты с открытым исходным кодом.

Answer 6

Один из подходов - привести библиотеки с открытым исходным кодом, которые вы используете, под свой собственный контроль исходного кода. Затем периодически объединяйте вышестоящие изменения в следующую ветку релиза или, скорее, если они являются исправлениями безопасности, и запускайте автоматизированные тесты.

Другими словами, используйте те же критерии, чтобы решить, следует ли использовать исходные изменения, как вы делаете для циклов выпуска в коде, который вы пишете сами. Считайте разработчиков с открытым исходным кодом частью вашей виртуальной команды разработчиков. В любом случае, это действительно так, вопрос только в том, решите ли вы признать это как часть своей практики разработки.

Answer 7

Некоторые важные вопросы:

• Насколько широко используется библиотека? (Если он широко используется, ошибки будут обнаружены и устранены быстрее)
• Насколько активно оно развито?
• Документация очень ясная?
• Были ли серьезные изменения, незначительные или просто внутренние изменения?
• Не нарушает ли обновление обратную совместимость? (Придется ли вам менять какой-либо код?)

Если обновление не выглядит плохо в соответствии с вышеуказанными критериями, лучше пойти с ним, и если у вас возникнут проблемы, вернитесь к старой версии.