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

9

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

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

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

Пересекать
источник
1
Я думаю, что ты прибил это.
Майк Партридж
4
Я никогда не верну много часов своей жизни, потраченных на сломанные установки Maven. Я убедился в том, что, несмотря на благие намерения, в большой корпорации это в конечном итоге станет беспорядочным беспорядком, который высасывает жизнь из вас, пока вы не превратились в пустую раковину.
MrFox
1
@suslik Хотите уточнить, что такое «сломанный Maven»?
Эндрю Т Финнелл
1
@AndrewFinnell Скажем, есть 5 групп, работающих над проектами, которые вам нужно задействовать для сборки, и из-за плохой координации все в конечном итоге зависят от разных версий библиотек. Затем оказывается, что один из проектов еще не был «выпущен», но (никто не сказал maven!) У вас есть зависимость, которую вы должны удовлетворить. Этого «не должно быть», но автоматическое разрешение делает это слишком простым. Если бы у каждого был каталог / libs, который нужно сохранить в svn, это заставило бы людей остановиться и задать вопросы, прежде чем все вышло из-под контроля.
MrFox
2
@MrFox Это действительно из-за плохой координации, а не из-за разрешения зависимостей Maven. Я сталкивался с такими же ситуациями, и я не фанат Maven, но я думаю, что инструменты не должны решать связанные с человеком проблемы, такие как преждевременные выпуски, отсутствие связи, отсутствие тестирования, плохое обслуживание и т. Д.
scriptin

Ответы:

8

Я не уверен на 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 сторонних команд. Я просто указываю, что это не все розы. Я оцениваю, если я должен избавиться от беседки для моих нужд, например.

GMan
источник
Вау, много отрицательных голосов и ни одного оправдания для них. Отличная работа! :(
Гман
Я никогда не использовал беседку, но необходимость installкаждый раз, когда вы оформляете заказ, кажется недостатком дизайна. Он должен проверить его конфигурацию при сборке проекта: если есть изменения, он должен перестроиться с нуля. Кроме того, перемещение репо не имеет отношения к Maven, поскольку оно извлекает артефакты из репозитория Maven, в котором хранятся артефакты, а не реальные репозитории с кодом. Вы можете только изменить artifactIdи groupIdв следующей версии вашего артефакта , если вы опубликовать его в Maven хранилище. Таким образом, ваши пункты № 1 и № 4 в основном не имеют отношения к Maven особенно. # 3 можно заменить mvn clean(иногда)
scriptin
Будучи правдой, № 2 не является недостатком - это компромисс. Конечно, вы должны изучить свои инструменты! Например, Git довольно сложно понять, но я не собираюсь отказываться от него из-за dem noobs.
Scriptin
1

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

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

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

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

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

Гэри Роу
источник
Я смотрел на The Twelve Factor App, но это очень спорный, и лишь очень немного актуальна. Кроме того, нажатие Maven не помогает мне объяснить, зачем нам нужно внедрение зависимостей. В целом, этот ответ не помогает мне продавать Dependency Injection, просто говорит мне много вещей, которые мне нужно сделать для процесса сборки.
К. Росс
2
Внедрение зависимостей (шаблон проектирования) - это не управление зависимостями (шаблон построения). Вы уже рассмотрели все наиболее важные аспекты вашего вопроса. Если ваша команда по-прежнему нуждается в убеждении, услышав это, то окончательное решение должно стать тем, к чему приведет Dependency Management.
Гари Роу
0

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

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

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

Росс Паттерсон
источник
2
Чем это отличается от проверки зависимостей? Фактически, если вы не проверяете зависимости, вы рискуете, что какая-то третья сторона нарушит ваш дистрибутив. У меня такое случалось не раз, когда какая-то беседка указывает на репо, которого кто-то удалил или переименовал. Если бы я только что скопировал источник в наш репозиторий, эта проблема исчезла.
Человек