В настоящее время я пытаюсь обосновать необходимость внедрения управления зависимостями для сборок (например, Maven, Ivy, NuGet) и создания внутреннего репозитория для общих модулей, из которых у нас более десятка предприятий. Каковы основные преимущества этой техники сборки? Те, что у меня есть:
- Облегчает процесс распространения и импорта общих модулей, особенно обновления версий.
- Требует, чтобы зависимости общих модулей были точно задокументированы.
- Удаляет общие модули из системы контроля версий, ускоряя и упрощая проверки / проверки (если у вас есть приложения с более чем 20 библиотеками, это реальный фактор) .
- Позволяет лучше контролировать или понимать, какие сторонние библиотеки используются в вашей организации.
Есть ли какие-то пункты продажи, которые мне не хватает? Есть ли какие-либо исследования или статьи, дающие метрики улучшения?
dependency-management
Пересекать
источник
источник
Ответы:
Я не уверен на 100% в положительном. Вот несколько минусов
Вы часто добавляете зависимости к сторонним серверам / конечным точкам, которые могут быть нестабильными.
У меня случалось с Бауэром, что репо некоторых зависимостей было удалено или перемещено. Таким образом, появляется новый разработчик, клонирует мое хранилище, печатает
bower install
и получает ошибки для недоступных хранилищ. Если вместо этого я зарегистрировал сторонний код в своем репо, эта проблема исчезнет.Это решается так, как предлагает ОП, если вы извлекаете депы из копий, хранящихся на запущенном сервере.
Тяжелее для новичков.
Я работаю со студентами-искусителями с очень небольшим опытом командной строки. Они занимаются искусством с помощью Processing, arduino, Unity3D, и обходятся очень мало технических знаний. Они хотели использовать HTML5 / JavaScript, который я написал. Шаги из-за беседки
npm install -g bower
)bower install
(наконец, чтобы получить наши зависимости)Все шаги 2-5 можно удалить, если мы просто зарегистрируем файлы в нашем репозитории github. Эти шаги, вероятно, звучат очень легко для вас и меня. Студентам они были очень запутаны, и они хотели знать, что все шаги, где и для чего они могли бы быть хорошим обучением, возможно, но были полностью ортогональны к теме класса и, вероятно, быстро забыты.
Это добавляет еще один шаг при вытягивании.
Это случалось много раз, когда я выполняю,
git pull origin master
а затем тестирую свой код, и требуется 5–10 минут, чтобы вспомнить, что мне нужно было набирать текст,bower install
чтобы получить последние deps. Я уверен, что это легко решается с помощью некоторого скрипта-хука.Это делает git более сложным
Если у 2 веток разные депы, ты как-то облажался. Я полагаю, вы можете печатать
bower install
после каждогоgit checkout
. Так много для скорости.Что касается ваших позитивов, я думаю, что есть контрпримеры к каждому из этих
против чего? Разумеется, распространять не легче. Вытащить один репо вместо 20 не проще и с большей вероятностью провалится. См. № 1 выше
И наоборот, это означает, что вы зависите от других для исправлений. Это означает, что если ваши deps извлекают данные из сторонних источников и вам нужно исправить ошибку, вам нужно подождать, пока они применят ваш патч. Хуже того, вы, вероятно, не можете просто взять нужную версию плюс ваш патч, вам придется взять последнюю версию, которая может быть обратно несовместима с вашим проектом.
Вы можете решить эту проблему, клонируя их репозитории отдельно, а затем вы указываете свои проекты на свои копии. Затем вы применяете любые исправления к своим копиям. Конечно, вы также можете сделать это, если просто скопировать источник в репозиторий.
Это кажется спорным. Просто потребуйте, чтобы разработчики поместили сторонние библиотеки в свою собственную папку
<ProjectRoot>/3rdparty/<nameOfDep>
. Так же легко увидеть, какие сторонние библиотеки используются.Я не говорю, что нет никаких позитивов. Последняя команда, в которой я участвовал, имела> 100 сторонних команд. Я просто указываю, что это не все розы. Я оцениваю, если я должен избавиться от беседки для моих нужд, например.
источник
install
каждый раз, когда вы оформляете заказ, кажется недостатком дизайна. Он должен проверить его конфигурацию при сборке проекта: если есть изменения, он должен перестроиться с нуля. Кроме того, перемещение репо не имеет отношения к Maven, поскольку оно извлекает артефакты из репозитория Maven, в котором хранятся артефакты, а не реальные репозитории с кодом. Вы можете только изменитьartifactId
иgroupId
в следующей версии вашего артефакта , если вы опубликовать его в Maven хранилище. Таким образом, ваши пункты № 1 и № 4 в основном не имеют отношения к Maven особенно. # 3 можно заменитьmvn clean
(иногда)Взгляните на приложение «Двенадцать факторов»
В частности, прочитайте о том, что они говорят о зависимостях . Вы заметите, что хороший дизайн обеспечивает декларативный механизм для определения зависимостей, в Java это часто реализуется через Maven. Ivy и NuGet работают отлично, но Maven в настоящее время является лидером в этой области, а Ivy решительно трудится.
Если вы придерживаетесь процесса выпуска Maven (разрабатывайте снимки до тех пор, пока формальный выпуск не будет готов, никогда не пытайтесь перезаписать предыдущий выпуск, используйте подходящий менеджер репозитория, такой как Nexus или Artifactory), тогда у вас должен быть процесс сборки, который приятно повторяется.
Если у вас есть надежный декларативный процесс сборки, он открывает двери для других полезных практик, таких как непрерывная интеграция с Jenkins , непрерывный анализ кода с Sonar, и вы обнаружите, что ищите лучшую стратегию ветвления контроля версий с использованием git .
Каждый из перечисленных выше основывается на ядре Maven. В наши дни это довольно простое решение.
источник
И № 1 в нашем топ-10 список ...
(барабанная дробь)
Каждый разработчик строит с одинаковыми версиями всех зависимостей, поэтому вам никогда не придется задумываться над тем, что развертывать в рабочей среде.
источник