Jak mogę uzasadnić „zarządzanie zależnościami”?

Obecnie próbuję uzasadnić przyjęcie zarządzania zależnościami dla kompilacji (ala Maven, Ivy, NuGet) i utworzenie wewnętrznego repozytorium dla modułów współdzielonych, z których mamy kilkanaście przedsiębiorstw. Jakie są główne zalety tej techniki budowy? Te, które do tej pory mam:

Ułatwia proces dystrybucji i importowania współdzielonych modułów, zwłaszcza aktualizacji wersji.
Wymaga dokładnego udokumentowania zależności współdzielonych modułów.
Usuwa współdzielone moduły z kontroli źródła, przyspieszania i upraszczania operacji pobierania / rejestrowania _{(w przypadku aplikacji z ponad 20 bibliotekami jest to prawdziwy czynnik)} .
Umożliwia większą kontrolę lub świadomość, jakie biblioteki stron trzecich są wykorzystywane w Twojej organizacji.

Czy brakuje mi punktów sprzedaży? Czy są jakieś badania lub artykuły dające wskaźniki poprawy?

dependency-management

— Krzyż
źródło

Myślę, że to przybiłeś.

— Mike Partridge

Nigdy nie odzyskam wielu godzin życia zmarnowanych na zepsute konfiguracje Maven. Przekonałem się, że niezależnie od dobrych intencji, w dużym korpusie, w końcu stanie się nieopanowanym bałaganem, który wysysa z ciebie życie, dopóki nie będziesz pustą skorupą.

— MrFox,

@suslik Czy zastanawiasz się, czym jest konfiguracja „zepsutego Mavena”?

— Andrew T Finnell,

@AndrewFinnell Powiedzmy, że istnieje 5 grup pracujących nad projektami, które należy pobrać, aby kompilacja mogła się skompilować, a ze względu na słabą koordynację wszyscy kończą w zależności od różnych wersji bibliotek. Okazuje się, że jeden z projektów nie miał być jeszcze „wydany”, ale (nikt nie powiedział mavenowi!) Masz zależność, którą musisz zaspokoić. Nie powinno się to „zdarzać”, ale automatyczna rozdzielczość sprawia, że jest to zbyt łatwe. Gdyby każdy miał katalog / libs do utrzymania w svn, zmusiłoby to ludzi do zatrzymania się i zadawania pytań, zanim sprawy wymkną się spod kontroli.

— MrFox,

@MrFox To rzeczywiście jest spowodowane słabą koordynacją, a nie rozwiązywaniem zależności Mavena. Doświadczyłem takich samych sytuacji i nie jestem fanem Maven, ale myślę, że narzędzia nie powinny rozwiązywać problemów związanych z ludźmi, takich jak przedwczesne wydania, brak komunikacji, brak testów, słaba konserwacja itp.

— scriptin

Odpowiedzi:

Nie jestem w 100% pewien co do pozytywów. Oto kilka negatywów

Często kończy się dodawanie zależności do serwerów / punktów końcowych innych firm, które mogą nie być stabilne.

Zdarzyło mi się z altaną, że repozytorium niektórych zależności zostało usunięte lub przeniesione. Tak więc pojawia się nowy programista, klonuje moje repozytorium, pisze bower installi wyświetla błędy dla niedostępnych repozytoriów . Jeśli zamiast tego zarejestrowałem w repozytorium kod innej firmy, problem zniknie.

Zostało to rozwiązane, jak sugeruje OP, jeśli wyciągasz depresje z kopii przechowywanych na uruchomionym serwerze.
Trudniej dla noobów.

Pracuję ze studentami sztuki z bardzo małym doświadczeniem z linii poleceń. Tworzą sztukę dzięki Processing, arduino, Unity3D i radzą sobie z bardzo małą wiedzą techniczną. Chcieli użyć napisanego przeze mnie HTML5 / JavaScript. Kroki z powodu altany
1. Pobierz Zip repo z github (uwaga znajduje się po prawej stronie każdego repo w github. Ponieważ nie znają git)
2. Pobierz i zainstaluj węzeł (abyśmy mogli uruchomić npm, aby zainstalować altanę)
3. Zainstaluj git lub msysgit (ponieważ bower tego wymaga i nie jest zainstalowany na komputerach wielu uczniów)
4. Zainstaluj altanę ( npm install -g bower)
5. bower install (wreszcie, aby uzyskać nasze zależności)
Kroki 2–5 można usunąć, jeśli tylko zarejestrujemy pliki w naszym repozytorium github. Te kroki prawdopodobnie brzmią bardzo łatwo dla ciebie i dla mnie. Uczniowie byli bardzo zagubieni i chcieli wiedzieć, jakie są wszystkie kroki i po co są, co może być dobrą nauką, ale jest całkowicie ortogonalne w stosunku do tematu zajęć i dlatego prawdopodobnie szybko zapomniane.
Dodaje kolejny krok podczas ciągnięcia.

Zdarzyło się to wiele razy, git pull origin mastera następnie testowałem swój kod, a zapamiętanie go wymagało pisania bower install od 5 do 10 minut, aby uzyskać najnowsze informacje. Jestem pewien, że łatwo to rozwiązać za pomocą haka do ściągania skryptów.
Utrudnia to rozgałęzianie gita

Jeśli 2 gałęzie mają różne obciążenia, to jesteś zepsuty. Podejrzewam, że możesz pisać bower installpo każdym git checkout. Tyle o szybkości.

Co do twoich pozytywów, myślę, że są przeciwne przykłady dla każdego z nich

Ułatwia proces dystrybucji i importowania współdzielonych modułów, zwłaszcza aktualizacji wersji.

vs co? Z pewnością nie jest łatwiej go rozpowszechniać. Wykonanie jednego repo zamiast 20 nie jest łatwiejsze i bardziej prawdopodobne jest, że się nie powiedzie. Zobacz # 1 powyżej

Usuwa współdzielone moduły z kontroli źródła, przyspieszania i upraszczania operacji pobierania / rejestrowania (w przypadku aplikacji z ponad 20 bibliotekami jest to prawdziwy czynnik).

I odwrotnie, oznacza to, że jesteś zależny od innych poprawek. Oznacza to, że jeśli twoi deps pobierają ze źródła zewnętrznego i potrzebujesz naprawionego błędu, musisz poczekać, aż zastosują łatkę. Co gorsza, prawdopodobnie nie możesz po prostu wziąć żądanej wersji plus łatki, musisz wziąć najnowszą wersję, która może nie być wstecznie kompatybilna z twoim projektem.

Możesz rozwiązać ten problem poprzez oddzielne klonowanie repozytoriów, a następnie wskazywanie zależności projektu od kopii. Następnie zastosujesz poprawki do swoich kopii. Oczywiście możesz to zrobić, jeśli po prostu skopiujesz źródło do repozytorium

Umożliwia większą kontrolę lub świadomość, jakie biblioteki stron trzecich są wykorzystywane w Twojej organizacji.

To wydaje się dyskusyjne. Wystarczy, że deweloperzy umieszczą biblioteki stron trzecich we własnym folderze <ProjectRoot>/3rdparty/<nameOfDep>. Równie łatwo jest zobaczyć, jakie biblioteki lib osób trzecich są używane.

Nie twierdzę, że nie ma pozytywów. Ostatni zespół, w którym byłem, miał> 100 oddziałów 3rd party. Po prostu wskazuję, że to nie wszystkie róże. Na przykład oceniam, czy powinienem pozbyć się altany na własne potrzeby.

— gman
źródło

Wow, wiele negatywnych głosów i nie ma dla nich ani jednego uzasadnienia. Dobra robota! :(

— gman

Nigdy nie korzystałem z altany, ale potrzeba za installkażdym razem, gdy kasujesz, wydaje się wadą projektową. Powinien sprawdzić swoją konfigurację podczas budowania projektu: jeśli są zmiany, powinien odbudować od zera. Ponadto przenoszenie repozytoriów nie ma znaczenia dla Maven, ponieważ pobiera artefakty z repozytorium Maven, które przechowuje artefakty, a nie repozytorium z kodem. Możesz zmienić artifactIdi groupIdw następnej wersji artefaktu jedynie, jeśli opublikujesz go w repozytorium Maven. Twoje punkty 1 i 4 są w większości nieistotne dla Mavena. # 3 można zastąpić mvn clean(czasami)

— scriptin

Prawda # 2 nie jest wadą - jest to kompromis. Oczywiście musisz nauczyć się swoich narzędzi! Na przykład Git jest dość trudny do zrozumienia, ale nie zamierzam się z niego poddawać z powodu dem noobów.

— scriptin

Spójrz na aplikację The Twelve Factor

W szczególności przeczytaj o tym, co mają do powiedzenia na temat zależności . Zauważysz, że dobry projekt zapewnia deklaratywny mechanizm lokalizowania zależności, w Javie jest to często realizowane przez Maven. Ivy i NuGet działają dobrze, ale Maven jest obecnie liderem w tej dziedzinie, a Ivy jest zdecydowanie ciężką pracą.

Jeśli zastosujesz się do procesu wydawania Maven (opracowuj migawki, dopóki formalne wydanie nie będzie gotowe, nigdy nie próbuj zastępować poprzedniego wydania, użyj odpowiedniego menedżera repozytorium, takiego jak Nexus lub Artifactory), powinieneś mieć proces kompilacji, który ładnie szumi.

Po wdrożeniu solidnego deklaratywnego procesu kompilacji otwiera on drzwi do innych dobrych praktyk, takich jak Continuous Integration with Jenkins , Continuous Code Analysis with Sonar, a potem szukasz lepszej strategii rozgałęziania kontroli wersji za pomocą git .

Każda z powyższych opiera się na rdzeniu Maven. W dzisiejszych czasach jest to decyzja, która nie wymaga myślenia.

— Gary Rowe
źródło

Spojrzałem na aplikację Twelve Factor, ale jest ona bardzo kontrowersyjna i tylko bardzo mała jest istotna. Również popychanie Maven nie pomaga mi wyjaśnić, dlaczego potrzebujemy zastrzyku zależności. Ogólnie rzecz biorąc, ta odpowiedź nie pomaga mi w sprzedaży wstrzykiwania zależności, po prostu mówi mi wiele rzeczy, które muszę zrobić w procesie kompilacji.

— C. Ross

Wstrzykiwanie zależności (wzorzec projektu) nie jest funkcją zarządzania zależnościami (wzorzec kompilacji). W swoim pytaniu omówiłeś już wszystkie najważniejsze aspekty. Jeśli twój zespół nadal potrzebuje przekonania po ich wysłuchaniu, to przekonanie się, do czego doprowadzi zarządzanie zależnościami, powinno być ostatnim przekonującym.

— Gary Rowe,

I numerem 1 na naszej liście 10 najlepszych jest ...

(werble)

Każdy programista tworzy dokładnie te same wersje wszystkich zależności, więc nigdy nie musisz się zastanawiać, co wdrożyć w środowisku produkcyjnym.

— Ross Patterson
źródło

Czym to się różni od sprawdzania zależności? W rzeczywistości, jeśli nie sprawdzisz zależności, ryzykujesz, że ktoś trzeci złamie twoją dystrybucję. Zdarzyło mi się to więcej niż raz, gdy jakiś deptak altówki wskazuje na repozytorium, które ktoś usunął lub którego nazwę zmieniono. Jeśli właśnie skopiowałem źródło do naszego repozytorium, problem zniknie.

— gman