Wie kann ich mich für ein „Abhängigkeitsmanagement“ aussprechen?

Ich versuche derzeit, das Abhängigkeitsmanagement für Builds (ala Maven, Ivy, NuGet) zu übernehmen und ein internes Repository für gemeinsam genutzte Module zu erstellen, von denen wir über ein Dutzend unternehmensweit haben. Was sind die Hauptverkaufsargumente dieser Bautechnik? Die, die ich bisher habe:

Erleichtert das Verteilen und Importieren freigegebener Module, insbesondere von Versions-Upgrades.
Erfordert eine genaue Dokumentation der Abhängigkeiten gemeinsam genutzter Module.
Entfernt gemeinsam genutzte Module aus der Quellcodeverwaltung, beschleunigt und vereinfacht das Auschecken / Einchecken _{(wenn Sie Anwendungen mit mehr als 20 Bibliotheken haben, ist dies ein echter Faktor)} .
Ermöglicht mehr Kontrolle oder Kenntnis darüber, welche Bibliotheken von Drittanbietern in Ihrer Organisation verwendet werden.

Gibt es Verkaufsargumente, die mir fehlen? Gibt es Studien oder Artikel, die Verbesserungskennzahlen enthalten?

dependency-management

— Kreuz
quelle

Ich denke, du hast es geschafft.

— Mike Partridge

Ich werde niemals die vielen Stunden meines Lebens zurückbekommen, die ich mit kaputten Maven-Setups verschwendet habe. Ich bin davon überzeugt, dass es in einem großen Unternehmen ungeachtet der guten Absichten irgendwann zu einem ungepflegten Chaos kommen wird, das Ihnen das Leben raubt, bis Sie eine hohle Hülle sind.

— MrFox

@suslik Möchtest du näher erläutern, was ein "kaputtes Maven" -Setup ist?

— Andrew T Finnell

@AndrewFinnell Angenommen, es gibt 5 Gruppen, die an Projekten arbeiten, die Sie für die Kompilierung Ihres Builds benötigen, und aufgrund der schlechten Koordination hängt jeder von verschiedenen Versionen der Bibliotheken ab. Dann stellt sich heraus, dass eines der Projekte noch nicht "veröffentlicht" werden sollte, aber (niemand hat es Maven gesagt!) Sie haben eine Abhängigkeit, die Sie erfüllen müssen. Dies soll nicht passieren, aber die automatische Auflösung macht es zu einfach. Wenn jeder ein / libs-Verzeichnis in svn pflegen müsste, würde dies die Leute dazu zwingen, anzuhalten und Fragen zu stellen, bevor die Dinge außer Kontrolle geraten.

— MrFox

@ MrFox Das liegt in der Tat an der schlechten Koordination, nicht an der Auflösung der Maven-Abhängigkeit. Ich habe die gleichen Situationen erlebt und bin kein Fan von Maven, aber ich denke, dass Tools keine Probleme im Zusammenhang mit Menschen wie vorzeitige Veröffentlichungen, mangelnde Kommunikation, fehlende Tests, schlechte Wartung usw. lösen sollen

— scriptin

Antworten:

Ich bin mir nicht 100% sicher. Hier sind ein paar Negative

Am Ende fügen Sie häufig Abhängigkeiten zu Servern / Endpunkten von Drittanbietern hinzu, die möglicherweise nicht stabil sind.

Ich habe es mit bower passieren lassen, dass das Repo einiger Abhängigkeiten gelöscht oder verschoben wurde. Also kommt ein neuer Entwickler, klont mein Repo, tippt bower installund bekommt Fehler für nicht zugängliche Repos. Wenn ich stattdessen den Code eines Drittanbieters in mein Repo eingecheckt hätte, verschwindet dieses Problem.

Dies wird gelöst, wie es das OP vorschlägt, wenn Sie Deps von Kopien abrufen, die auf einem von Ihnen ausgeführten Server gespeichert sind.
Härter für Noobs.

Ich arbeite mit Kunststudenten mit sehr wenig Kommandozeilenerfahrung. Sie machen Kunst mit Processing, Arduino, Unity3D und kommen mit sehr wenig technischem Wissen aus. Sie wollten etwas HTML5 / JavaScript verwenden, das ich geschrieben habe. Schritte wegen Laube
1. Laden Sie Zip of Repo von Github herunter (beachten Sie, dass dies rechts von jedem Repo auf Github steht. Weil sie Git nicht kennen)
2. Laden Sie den Knoten herunter und installieren Sie ihn (damit wir npm ausführen können, um bower zu installieren).
3. Installieren Sie git oder msysgit (da bower es benötigt und es nicht auf den Computern vieler Schüler installiert ist)
4. Laube einbauen ( npm install -g bower)
5. bower install (endlich um unsere Abhängigkeiten zu bekommen)
Die Schritte 2 bis 5 können alle gelöscht werden, wenn wir nur die Dateien in unser Github-Repo einchecken. Diese Schritte klingen für Sie und mich wahrscheinlich sehr einfach. Für die Schüler waren sie sehr verwirrend und sie wollten wissen, welche Schritte wo und wofür sie waren, was möglicherweise ein gutes Lernen sein könnte , aber völlig orthogonal zum Klassenthema war und so wahrscheinlich schnell vergessen wurde.
Beim Hinzufügen wird ein weiterer Schritt hinzugefügt.

Es ist oft passiert, dass ich einen git pull origin masterCode mache und dann bower install teste. Es dauert 5 bis 10 Minuten, bis ich mich daran erinnere, dass ich tippen musste , um die neuesten Deps zu erhalten. Ich bin sicher, das lässt sich leicht mit einem Pull-Script-Hook lösen.
Es macht die Verzweigung von Git schwieriger

Wenn 2 Zweige unterschiedliche Deps haben, sind Sie irgendwie geschraubt. Ich nehme an, Sie können bower installnach jedem tippen git checkout. Soviel zur Geschwindigkeit.

Was Ihre positiven Aspekte betrifft, denke ich, dass es zu jedem dieser Beispiele Gegenbeispiele gibt

Erleichtert das Verteilen und Importieren freigegebener Module, insbesondere von Versions-Upgrades.

vs was? Es ist sicherlich nicht einfacher zu verteilen. Das Ziehen eines Repos anstelle von 20 ist nicht einfacher und schlägt eher fehl. Siehe Nr. 1 oben

Entfernt gemeinsam genutzte Module aus der Quellcodeverwaltung, beschleunigt und vereinfacht das Auschecken / Einchecken (wenn Sie Anwendungen mit mehr als 20 Bibliotheken haben, ist dies ein echter Faktor).

Umgekehrt bedeutet dies, dass Sie für Korrekturen von anderen abhängig sind. Das heißt, wenn Ihre Deps von einer Quelle eines Drittanbieters stammen und Sie einen behobenen Fehler benötigen, müssen Sie warten, bis sie Ihren Patch anwenden. Schlimmer noch, Sie können wahrscheinlich nicht nur die gewünschte Version und Ihren Patch verwenden, sondern müssen auch die neueste Version verwenden, die möglicherweise nicht abwärtskompatibel mit Ihrem Projekt ist.

Sie können dies lösen, indem Sie die Repos separat klonen und dann Ihre Projektabteilungen auf Ihre Kopien verweisen. Anschließend wenden Sie Korrekturen an Ihren Kopien an. Natürlich können Sie das auch tun, wenn Sie nur die Quelle in Ihr Repo kopieren

Ermöglicht mehr Kontrolle oder Kenntnis darüber, welche Bibliotheken von Drittanbietern in Ihrer Organisation verwendet werden.

Das scheint fraglich. Fordern Sie die Entwickler lediglich auf, Bibliotheken von Drittanbietern in einem eigenen Ordner unter abzulegen <ProjectRoot>/3rdparty/<nameOfDep>. Es ist genauso einfach zu sehen, welche Bibliotheken von Drittanbietern verwendet werden.

Ich sage nicht, dass es keine positiven Ergebnisse gibt. Das letzte Team, in dem ich war, hatte> 100 Deps von Drittanbietern. Ich weise nur darauf hin, dass es nicht nur Rosen sind. Ich überlege, ob ich zum Beispiel die Laube für meine Bedürfnisse loswerden soll.

— gman
quelle

Wow, viele negative Stimmen und keine einzige Rechtfertigung für sie. Gut gemacht! :(

— Gman

Ich habe noch nie eine Laube benutzt, aber die Notwendigkeit, installjedes Mal auszuchecken, scheint ein Designfehler zu sein. Es sollte seine Konfiguration überprüfen, wenn es ein Projekt erstellt: Wenn es Änderungen gibt, sollte es von Grund auf neu erstellt werden. Das Verschieben von Repos ist für Maven ebenfalls irrelevant, da Artefakte aus dem Maven-Repository abgerufen werden, in dem Artefakte gespeichert werden, nicht die tatsächlichen Repos mit Code. Sie können sich nur ändern , artifactIdund groupIdin der nächsten Version des Artefakts , wenn Sie es in Maven - Repository veröffentlichen. Daher sind Ihre Punkte 1 und 4 für Maven besonders irrelevant. # 3 kann ersetzt werden mvn clean(manchmal)

— scriptin

# 2 ist zwar wahr, aber kein Nachteil - es ist ein Kompromiss. Natürlich müssen Sie Ihre Werkzeuge lernen! Zum Beispiel ist Git ziemlich schwer zu verstehen, aber ich werde es wegen dem Noobs nicht aufgeben.

— Scriptin

Schauen Sie sich die Twelve Factor App an

Lesen Sie insbesondere, was sie über Abhängigkeiten zu sagen haben . Sie werden feststellen, dass gutes Design einen deklarativen Mechanismus zum Auffinden von Abhängigkeiten bietet. In Java wird dies häufig über Maven realisiert. Ivy und NuGet funktionieren gut, aber Maven ist derzeit führend auf diesem Gebiet und Ivy ist ausgesprochen harte Arbeit.

Wenn Sie sich an den Maven-Release-Prozess halten (entwickeln Sie Snapshots, bis eine formale Release fertig ist, versuchen Sie niemals, eine frühere Release zu überschreiben, verwenden Sie einen geeigneten Repository-Manager wie Nexus oder Artifactory), sollten Sie einen Build-Prozess haben, der gut läuft.

Sobald Sie einen soliden deklarativen Erstellungsprozess eingerichtet haben, öffnet sich die Tür zu anderen bewährten Methoden wie der kontinuierlichen Integration mit Jenkins und der kontinuierlichen Code-Analyse mit Sonar, und Sie werden nach einer besseren Verzweigungsstrategie für die Versionskontrolle mit git suchen .

Jedes der oben genannten Elemente baut auf dem Kern von Maven auf. Heutzutage ist es eine einfache Entscheidung.

— Gary Rowe
quelle

Ich habe mir die Twelve Factor App angesehen, aber sie ist äußerst umstritten und nur ein kleines bisschen ist relevant. Auch das Drücken von Maven hilft mir nicht zu erklären, warum wir eine Abhängigkeitsinjektion benötigen. Insgesamt hilft mir diese Antwort nicht, Dependency Injection zu verkaufen, sondern sagt mir nur eine Menge Dinge, die ich für meinen Build-Prozess tun muss.

— C. Ross

Dependency Injection (das Entwurfsmuster) ist nicht Dependency Management (das Erstellungsmuster). Sie haben bereits alle wichtigen Aspekte Ihrer Frage behandelt. Wenn Ihr Team nach Anhörung noch überzeugen muss, sollte es der endgültige Überzeuger sein, zu sehen, wozu das Abhängigkeitsmanagement führen wird.

— Gary Rowe

Und die Nummer 1 auf unserer Top 10 Liste ist ...

(Trommelwirbel)

Jeder Entwickler erstellt mit genau den gleichen Versionen aller Abhängigkeiten, sodass Sie sich nie fragen müssen, was in der Produktion bereitgestellt werden soll.

— Ross Patterson
quelle

Wie unterscheidet sich das vom Einchecken der Abhängigkeiten? Wenn Sie die Abhängigkeiten nicht einchecken, besteht die Gefahr, dass Dritte Ihre Distribution beschädigen. Ich habe dies mehr als einmal erlebt, als einige Bower Dep auf ein Repo verweisen, das jemand gelöscht oder umbenannt hat. Wenn ich nur die Quelle in unser Repo kopiert hätte, wäre dieses Problem behoben.

— Gman