Как я могу обосновать «управление зависимостями»?

В настоящее время я пытаюсь обосновать необходимость внедрения управления зависимостями для сборок (например, Maven, Ivy, NuGet) и создания внутреннего репозитория для общих модулей, из которых у нас более десятка предприятий. Каковы основные преимущества этой техники сборки? Те, что у меня есть:

• Облегчает процесс распространения и импорта общих модулей, особенно обновления версий.
• Требует, чтобы зависимости общих модулей были точно задокументированы.
• Удаляет общие модули из системы контроля версий, ускоряя и упрощая проверки / проверки _{(если у вас есть приложения с более чем 20 библиотеками, это реальный фактор)} .
• Позволяет лучше контролировать или понимать, какие сторонние библиотеки используются в вашей организации.

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

Я не уверен на 100% в положительном. Вот несколько минусов

1. Вы часто добавляете зависимости к сторонним серверам / конечным точкам, которые могут быть нестабильными.

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

   Это решается так, как предлагает ОП, если вы извлекаете депы из копий, хранящихся на запущенном сервере.

2. Тяжелее для новичков.

   Я работаю со студентами-искусителями с очень небольшим опытом командной строки. Они занимаются искусством с помощью Processing, arduino, Unity3D, и обходятся очень мало технических знаний. Они хотели использовать HTML5 / JavaScript, который я написал. Шаги из-за беседки

   1. Загрузите Zip репо с github (обратите внимание, что это справа от каждого репо на github. Потому что они не знают git)
   2. Скачать и установить узел (чтобы мы могли запустить npm для установки bower)
   3. Установите git или msysgit (потому что bower этого требует, и он не установлен на компьютерах многих студентов)
   4. Установите беседку ( npm install -g bower)
   5. bower install (наконец, чтобы получить наши зависимости)

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

3. Это добавляет еще один шаг при вытягивании.

   Это случалось много раз, когда я выполняю, git pull origin masterа затем тестирую свой код, и требуется 5–10 минут, чтобы вспомнить, что мне нужно было набирать текст, bower install чтобы получить последние deps. Я уверен, что это легко решается с помощью некоторого скрипта-хука.

4. Это делает git более сложным

   Если у 2 веток разные депы, ты как-то облажался. Я полагаю, вы можете печатать bower installпосле каждого git checkout. Так много для скорости.

Что касается ваших позитивов, я думаю, что есть контрпримеры к каждому из этих

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

против чего? Разумеется, распространять не легче. Вытащить один репо вместо 20 не проще и с большей вероятностью провалится. См. № 1 выше

Удаляет общие модули из системы контроля версий, ускоряя и упрощая проверки / проверки (если у вас есть приложения с более чем 20 библиотеками, это реальный фактор).

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

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

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

Это кажется спорным. Просто потребуйте, чтобы разработчики поместили сторонние библиотеки в свою собственную папку <ProjectRoot>/3rdparty/<nameOfDep>. Так же легко увидеть, какие сторонние библиотеки используются.

Я не говорю, что нет никаких позитивов. Последняя команда, в которой я участвовал, имела> 100 сторонних команд. Я просто указываю, что это не все розы. Я оцениваю, если я должен избавиться от беседки для моих нужд, например.

Взгляните на приложение «Двенадцать факторов»

В частности, прочитайте о том, что они говорят о зависимостях . Вы заметите, что хороший дизайн обеспечивает декларативный механизм для определения зависимостей, в Java это часто реализуется через Maven. Ivy и NuGet работают отлично, но Maven в настоящее время является лидером в этой области, а Ivy решительно трудится.

Если вы придерживаетесь процесса выпуска Maven (разрабатывайте снимки до тех пор, пока формальный выпуск не будет готов, никогда не пытайтесь перезаписать предыдущий выпуск, используйте подходящий менеджер репозитория, такой как Nexus или Artifactory), тогда у вас должен быть процесс сборки, который приятно повторяется.

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

Каждый из перечисленных выше основывается на ядре Maven. В наши дни это довольно простое решение.

И № 1 в нашем топ-10 список ...

(барабанная дробь)

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