Як я можу скласти справу про "управління залежністю"?

На даний момент я намагаюся зробити справу щодо прийняття управління залежностями для збірок (ala Maven, Ivy, NuGet) та створення внутрішнього сховища для спільних модулів, яких у нас є більше десятка підприємств у всьому світі. Які основні точки продажу цієї техніки побудови? Ті, які у мене є:

• Полегшує процес розповсюдження та імпорту спільних модулів, особливо оновлення версій.
• Вимагає, щоб залежності спільних модулів були точно задокументовані.
• Вилучає спільні модулі з керування джерелами, прискорення та спрощення реєстрації / реєстрації _{(якщо у вас є програми з 20+ бібліотеками, це справжній фактор)} .
• Дозволяє більше контролювати або усвідомлювати, які треті сторони використовують у вашій організації.

Чи є якісь пункти продажу, які мені не вистачає? Чи є дослідження чи статті, що дають показники покращення?

Я не впевнений на 100%. Ось кілька негативів

1. Часто ви додаєте залежності до сторонніх серверів / кінцевих точок, які можуть бути нестабільними.

   У мене траплялося, що з bower траплялося, що репортаж деяких залежностей було видалено або переміщено. Тож з'являється новий розробник, клонує моє репо, набирає bower installта отримує помилки для недоступних репостів. Якщо б замість цього я перевірив код третьої сторони у своєму репо, ця проблема зникає.

   Це вирішується так, як пропонує ОП, якщо ви витягуєте копії копій, що зберігаються на сервері, на якому ви працюєте.

2. Важко для ноб.

   Я працюю зі студентами мистецтва з дуже невеликим досвідом командного рядка. Вони творять мистецтво за допомогою Processing, arduino, Unity3D і отримують дуже мало технічних знань. Вони хотіли використовувати деякі HTML5 / JavaScript, які я написав. Кроки через бауер

   1. Завантажте Zip repo з github (зауважте, що справа від кожного репо на github. Тому що вони не знають git)
   2. Завантажте та встановіть вузол (щоб ми могли запустити npm для встановлення bower)
   3. Встановіть git або msysgit (тому що bower цього вимагає, і він не встановлений на багатьох учнівських машинах)
   4. Встановити базу ( npm install -g bower)
   5. bower install (нарешті, щоб отримати наші залежності)

   Кроки 2-5 можуть бути видалені, якщо ми просто перевіримо файли до нашого github repo. Ці кроки, ймовірно, звучать надто легко вам і мені. Студентам вони були дуже заплутані, і вони хотіли дізнатись, які всі кроки, де і для чого вони були, для чого, можливо, було б добре навчатись, але цілком ортогональне для класної теми і, швидше за все, швидко забуте.

3. Це додає ще один крок при витягуванні.

   Це трапляється багато разів, і я git pull origin masterтестую свій код, і потрібно 5 - 10 хвилин, щоб пам'ятати, що мені потрібно було набрати, bower install щоб отримати останні графіки. Я впевнений, що це легко вирішується за допомогою кнопок "pull pull script".

4. Це ускладнює розгалуження git

   Якщо на двох гілках є різні колодки, ви начебто накручені. Я думаю, ви можете вводити bower installпісля кожного git checkout. Стільки за швидкість.

Щодо ваших позитивних позицій, я думаю, що для кожного з них є приклади зустрічних

Полегшує процес розповсюдження та імпорту спільних модулів, особливо оновлення версій.

проти чого? Це звичайно не простіше розповсюджувати. Витягнути одне репо замість 20 не простіше і, швидше за все, не вдасться. Див. №1 вище

Видаляє спільні модулі з керування джерелами, прискорення та спрощення реєстрації / реєстрації (якщо у вас є програми з 20+ бібліотеками, це справжній фактор).

І навпаки, це означає, що ви залежите від інших для виправлень. Це означає, що якщо ваші депо витягуються з стороннього джерела і вам потрібна помилка, ви повинні зачекати, коли вони застосують ваш патч. Гірше, ви, мабуть, не можете просто взяти потрібну версію плюс ваш патч, вам доведеться взяти останню, яка може бути не сумісною з вашим проектом.

Ви можете вирішити це, клонувавши їх репост окремо, а потім наведіть деп-файли проекту на свої копії. Потім ви застосуєте будь-які виправлення до своїх копій. Звичайно, ви могли також зробити це, якщо просто скопіюєте джерело у своє репо

Дозволяє більше контролювати або усвідомлювати, які треті сторони використовують у вашій організації.

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

Я не кажу, що позитивів немає. В останній команді, на якій я був, було> 100 департів 3-го партії. Я просто вказую, що це не всі троянди. Я оцінюю, чи варто мені позбутися, наприклад, моїх потреб.

Погляньте на додаток The Twelve Factor

Зокрема читайте про те, що вони мають сказати про залежності . Ви помітите, що хороший дизайн забезпечує декларативний механізм для визначення залежностей, на Java це часто реалізується через Maven. Ivy та NuGet прекрасно працюють, але Мейвен на даний момент є лідером у цій галузі, і Айві, безумовно, важка робота.

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

Після того, як у вас є надійний процес декларативної збірки, він відкриває двері до інших належних практик, таких як Постійна інтеграція з Дженкінсом , постійний аналіз коду з Sonar, і ви знайдете собі кращу стратегію розгалуження версій управління за допомогою git .

Кожен із перерахованих вище будується на ядрі, що є Мейвен. В наші дні це, як правило, не-розумне рішення.

І пункт №1 у нашому першому списку 10 - це ...

(барабанний дріб)

Кожен розробник будує з абсолютно однаковими версіями всіх залежностей, тому вам ніколи не доведеться задаватися питанням, що розгорнути у виробництві.