Как обрабатывать основные обновления инфраструктуры / зависимостей?

Question

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

В частности, я заинтересован в:

• Как обновлять унаследованное приложение (например, Spring 1.2.x до 2.5.x)
• Какие методы могут быть применены после такого капитального ремонта, чтобы поддерживать приложения в актуальном состоянии

Мы приветствуем ваш собственный опыт или любые статьи / статьи, которые вы нашли / нашли полезными.

EDIT: Обновление номера версии зависимости тривиально. Я больше смотрю на то, как вы решаете, какие изменения необходимо внести, основываясь на изменениях в зависимости (устаревание, удаление, изменения типов в параметрах / возвращаемых значениях и т. Д.). И если есть хороший способ облегчить эти изменения в будущем, так как поддержание ваших зависимостей в актуальном состоянии должно позволить вам оставаться в курсе изменений и не тратить много времени просто на получение функция 'more securer x 2.1'.

Answer 1

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

Для незначительных обновлений (точечных обновлений зависимостей) полезно иметь полный набор модульных тестов для обнаружения сбоев из-за изменений API. Это одна из основных причин, почему иногда полезно писать тривиальные тесты, которые на первый взгляд кажутся работающими. Примером этого является написание простого модульного теста JDBC для выполнения простого запроса. Это кажется пустой тратой усилий, пока вы не обнаружите проблему с драйвером JDBC после обновления базы данных (это случилось со мной).

Для более крупных изменений (например, обновление между несовместимыми версиями инфраструктуры, такой как Spring), полезно, если у вас есть какие-то автоматические функциональные или интеграционные тесты, или, по крайней мере, есть функциональная спецификация, которую ваши сотрудники QA могут просмотреть для проверки функциональности высокого уровня , Модульные тесты, скорее всего, больше не будут актуальны, если обновляемый API-интерфейс платформы достаточно отличается, чтобы требовать широких изменений кода.

Фактическая тактическая часть управления миграцией из одной несовместимой версии в другую действительно зависит от того, что вы делаете. Зрелая библиотека обеспечит какой-то путь миграции и, надеюсь, не потребует от вас переписывать все. Рекомендуется отделять изменения кода, связанные с обновлением инфраструктуры, от изменений, связанных с реализацией новой функции. Таким образом, если что-то сломается, вы будете знать, что это связано с обновлением фреймворка, а не чем-то, что вы сломали при реализации новой функции.

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

Answer 2

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

Я всегда обнаруживал, что лучшие практики начинаются с завершения производства вашего приложения для цикла, выпуска его в качестве стабильной сборки и ручного обновления ваших зависимостей в следующей итерации разработки. Централизация ваших версий в родительском POM приведет к минимальным изменениям версий зависимостей и увеличенной расширяемости. Предполагая, что вы используете Maven:

<dependency>
   <groupId>your.dep.group</groupId>
   <artifactId>your-artifact-id</artifactId>
   <version>${desiredVersion}</version>
</dependency>