Лучшая практика управления зависимостями в проекте с огромным количеством зависимостей

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

1 ответ

Важная часть этого вопроса - процесс, а не инструменты.

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

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

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

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

licensed under cc by-sa 3.0 with attribution.