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

Допустим, у меня есть проект, который зависит от 10 библиотек, и в пределах ствола моего проекта я могу свободно использовать любые версии этих библиотек. Итак, я начну с самых последних версий. Затем каждая из этих библиотек получает обновление один раз в месяц (в среднем). Теперь, чтобы поддерживать мой багажник в актуальном состоянии, потребуется обновлять ссылку на библиотеку каждые три дня.

Это явно слишком много. Хотя обычно версия 1.2.3 является заменой версии 1.2.2, вы никогда не узнаете об этом без тестирования. Модульных тестов недостаточно; если это БД / файловый движок, вы должны убедиться, что он правильно работает с файлами, которые были созданы в более старых версиях, и, возможно, наоборот. Если это как-то связано с GUI, вам нужно все визуально осмотреть. И так далее.

Как вы справляетесь с этим? Некоторые возможные подходы:

• Если это не сломано, не исправляйте это . Оставайтесь с текущей версией библиотеки до тех пор, пока вы не заметите ничего плохого при ее использовании в приложении, независимо от того, как часто поставщик библиотеки публикует обновления. Небольшие постепенные изменения - просто пустая трата времени.
• Обновляйте часто, чтобы изменения не были небольшими. Поскольку в любом случае вам придется обновлять когда-нибудь, лучше обновлять часто, чтобы вы сразу заметили какие-либо проблемы, когда их легко исправить, вместо того, чтобы перепрыгивать через несколько версий и позволять накоплению потенциальных проблем.
• Что-то среднее. Есть сладкое место?

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

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

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

Теперь вопрос в том, что вы делаете, если обновление ломает вещи - вы тратите время на его исправление или упускаете его? Я бы предложил склоняться к последнему; если это можно исправить в течение часа, сделайте это, но если обновление потребует значительных усилий для интеграции, то поднимите его как свою собственную задачу разработки, чтобы оценить, расставить приоритеты и запланировать, как и любое другое. Скорее всего, если это не принесет какого-то очень важного исправления или улучшения, приоритет будет низким, и вы никогда не сможете его обойти. Но вы никогда не знаете, что к тому времени, когда наступит следующий итеративный день обновления, проблема, возможно, решится сама собой; даже если нет, по крайней мере теперь вы знаете, что на пути обновления есть препятствие, и оно не застигнет вас врасплох.

Если вы не выполняете итерации такой длины, я бы установил какой-то отдельный график обновлений - не дольше, чем раз в месяц. Есть ли какой-то другой ритм проекта, к которому вы могли бы привязать его, например, ежемесячный обзор состояния или заседание совета по архитектуре? Payday? Пицца ночью? Полнолуние? Как бы то ни было, вам нужно найти что-то намного короче, чем традиционный цикл выпуска, потому что попытка обновлять все за один раз каждые 6-18 месяцев будет болезненной и деморализующей.

Само собой разумеется, что если вы делаете стабилизационные ветки перед выпусками, вы не примените к ним эту политику. Там вы только обновите библиотеки, чтобы получить критические исправления.

Я оцениваю

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

Затем я сравниваю все это с тем, чтобы остаться с существующей библиотекой.

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

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

Обычно это делается при выпуске новой версии.

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

Частично, как описано в ветках svn vendor . Описанная там процедура очень полезна, если вы продолжаете использовать сторонние библиотеки с открытым исходным кодом в течение длительного времени и вносите изменения, чтобы приспособить ее к вашим потребностям.

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

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

Вы должны спросить, что вы действительно хотите от обновления? Большинство исправлений безопасности на самом деле являются тривиальными исправлениями в форме исправлений:

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

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

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

Наконец, у вас есть новые функции ... и, возможно, устаревшие функции. Вы должны внимательно изучить эти заметки о выпуске и различия. Можете ли вы использовать их, даже если они нарушают API, от которого зависит множество других вещей? Если да, то пришло время для операции .. если нет, вишня выбрать то, что вы хотите, и двигаться дальше.

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

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

В идеале у вас всегда будет самая свежая версия, но если новая версия не имеет обратной совместимости, что тогда? Возможно, вам придется отложить это обновление до следующего выпуска, пока вы не сможете тщательно обработать это изменение. Может быть небольшое изменение в поведении (например, «теперь вам нужно установить свойство X перед вызовом метода Y, или вы получаете медленную утечку памяти»), что трудно проверить при тестировании.

С другой стороны, в новой версии могут быть серьезные исправления безопасности, поэтому вы должны принять это во внимание.

Краткая версия: принимайте это в каждом конкретном случае.

Это будет зависеть от ваших графиков выпуска.

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

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

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

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

Subversion Externals

Отличительной особенностью этой функции является то, что вы можете указать нужную вам ревизию.

Обратите внимание, что обновления будут медленнее, если у вас много внешних.

Я сейчас настраиваю что-то вроде этого:

• 1 ртутный репо для каждого расширения моего приложения
• Mercurial репо, которые собирают конкретные версии нескольких сторонних библиотек
• репозиторий SVN для графических ресурсов / работ (но может измениться на что-то другое)
• Mercurial Repo для моего приложения, который использует функцию Mercurial Subrepos для использования конкретной версии 3-го Pare репо и некоторых основных расширений.

Теперь, когда мне нужно поработать над расширением, которое не является «базовым» (неявно включенным в качестве репо в репо приложения), я просто получаю клон репо в папке расширений и позволяю CMake генерировать проекты и решения для всего приложения.

Таким образом, я могу:

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

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

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

В противном случае, когда библиотека зрелая, это «Если она не сломана, не исправляйте ее». для меня. Рано или поздно мне может понадобиться функция более поздней версии, и у меня не будет другого выбора, кроме как обновить ее, но пока усилия трудно оправдать. С другой стороны, когда я работаю с относительно новой библиотекой или фреймворком, таким как Grails или ExtJS, я остаюсь в курсе последних версий, потому что эти продукты еще не совсем созрели, поэтому обновление, скорее всего, спасет меня. из-за появления одной из этих ошибок исправлена ​​более поздняя версия.

Я использую NuGet, чтобы поддерживать свои сторонние библиотеки в актуальном состоянии.

Когда друг, коллега или блог уведомляет меня о том, что одна из моих сторонних библиотек DLL устарела, NuGet позволяет очень легко ее обновить.