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

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

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

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

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

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

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

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

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