Ist es empfehlenswert, Framework-Laufzeiten unter Quellcodeverwaltung zu speichern?

Ich weiß, dass viele Software-Shops Binärdateien unter Quellcodeverwaltung halten . Unser Shop war jedoch dazu gekommen, ganze Frameworks im Repository zu speichern: DirectX-Laufzeit, CUDA, nVidia Optix, was auch immer.

Es soll die Einrichtung einer Entwicklungsmaschine erleichtern (angeblich die neueste Version erhalten und mit dem Codieren beginnen). Das Repository wird jedoch erheblich aufgebläht und mit irrelevanter Historie belastet.

Ich habe noch nie ein solches Nutzungsmuster gesehen. Halten Sie es für eine gute Praxis?

[EDIT:] Ich habe kein Problem mit der Quellcodeverwaltung isolierter Binärdateien von Drittanbietern. Die Frage bezieht sich auf ganze Framework-Laufzeiten, die normalerweise aus mehr als 10 Binärdateien bestehen. Nehmen Sie als extremes Beispiel das Windows SDK (das wir Gott sei Dank nicht im Repository behalten, aber ich sehe im Prinzip keinen Unterschied).

Binärdateien sind im Allgemeinen nicht gut für Versionskontrollsysteme geeignet, weil:

• Sie profitieren nicht von Versionskontrollfunktionen (Merge, Diff).
• Sie vergrößern das Repo ...
• ... was wichtig ist, weil Sie eine Version nicht einfach aus einem VCS entfernen können (VCS dient zum Speichern des Verlaufs), im Gegensatz zu Artefakt-Repositorys wie Nexus , bei denen es sich um einfache gemeinsam genutzte Verzeichnisse handelt (einfach zu bereinigen: cd+ rm!).
• Sie sollten in einem VCS als Text , als Deklaration von Pfad + Version , referenziert werden : Auf diese Weise können Sie den relevanten Verlauf beibehalten und jede Änderung der Binärversion als Änderung in dieser Textdatei aufzeichnen (wie eine pom.xml, wenn Sie Nexus verwenden zum Beispiel)

Ich bin mit der Versionskontrolle von binären Assets einverstanden. Ich bin gegen die Versionskontrolle generierter Dateien.

Das Setup der Umgebung unterscheidet sich auch von der Entwicklung. Wir entwickeln hauptsächlich in Python und es hat ein Tool namens virtualenv, mit dem Sie eine leichtgewichtige isolierte Umgebung (einschließlich Bibliotheken) für ein Projekt erstellen können. Wenn wir unsere Quellen auschecken, haben wir dort ein Setup-Skript, das diese virtuelle Umgebung erstellt. Mithilfe eines Manifests gibt dies an, welche Versionen von Bibliotheken benötigt werden und andere solche Dinge. Nichts davon ist versioniert. Nur das Setup-Skript ist.

Wenn Sie das gesamte Framework unter Ihr Hauptprojekt werfen, wird Ihre Geschichte unübersichtlich und die Dinge ernsthaft durcheinander gebracht. Es ist nicht Teil Ihres Projekts und sollte anders behandelt werden.

Im Allgemeinen ist es eine gute Idee, das Konfigurationsmanagement mit Framework-Versionen durchzuführen. Wenn Ihr Code eine bestimmte DirectX-Version benötigt, sollte diese Version leicht verfügbar sein, und wenn Sie eine ältere Version Ihrer Software auschecken, sollte es einfach sein, festzustellen, welche externen Abhängigkeiten sie hat.

Was ich hier nicht für eine gute Idee halte, ist die Verwendung eines typischen Versionskontrollsystems zum Speichern dieser Binärdateien. In unserem Unternehmen speichern wir jede Version von Frameworks, Bibliotheken und externen Tools in einer Unterordnerstruktur auf einem Netzlaufwerk. Wo wir es für sinnvoll halten, haben wir Readme-Dateien, um zu dokumentieren, welche Tool-Version zu welcher Software-Version gehört, oder, wenn möglich, Skripte zur Installation oder Verwendung einer bestimmten Version. Nur diese Readme-Dateien und Skripte werden in die Versionskontrolle übernommen.

Wir behalten auch ältere Versionen von Tools und Bibliotheken bei, solange wir glauben, dass die Möglichkeit besteht, dass wir abhängig von diesen Tools eine ältere Version neu erstellen müssen. Auf diese Weise haben wir die Möglichkeit, einige der sehr alten Bibliotheken und Tools von unserem Netzwerklaufwerk zu löschen, wenn sie veraltet sind (natürlich nur für den Fall, dass wir Archive auf externen Medien haben).

Ich denke, dass die Binärdateien irgendwo gespeichert werden sollten. Ich würde empfehlen, sie außerhalb eines Repositorys zu speichern, insbesondere wenn sie groß sind und zu langen Check-out-Zeiten führen. Ich werde nicht sehen, dass es eine schlechte Praxis ist, aber es ist auch keine, die ich gesehen habe.

Dies kann tatsächlich eine gute Idee sein, wenn Ihre Organisation viele Projekte hat, die auf verschiedene Laufzeitversionen abzielen. Es stellt sicher, dass Sie die richtige Laufzeit-Binärdatei haben, wenn Sie an den richtigen Projekten arbeiten.

Ich persönlich halte dies für eine sehr schlechte Praxis. Ich bevorzuge es, ein Wiki mit Installationsanweisungen einzurichten und die erforderlichen Binärdateien hochzuladen. Diese Dateien werden nur von neuen Entwicklern benötigt. Es ist nicht erforderlich, die Repositorys aller anderen Benutzer aufzublähen.

Dafür gibt es einen guten Grund: Sie haben alles, was Sie brauchen, an einem einzigen Ort, ohne externe Abhängigkeiten.

Dies ist viel wichtiger als Sie vielleicht denken. Es stellt im Wesentlichen sicher, dass Sie sich nicht auf ein Artefakt auf einem Anbieterserver verlassen, das nach einigen Jahren möglicherweise nicht mehr verfügbar ist, da Sie alles intern haben.

In Bezug auf Repository aufblähen. Dies ist nur dann ein Problem, wenn Ihr VCS eine vollständige lokale Kopie behält (git tut dies, cvs nicht), da das Klonen und / oder Aktualisieren langsam ist. Im Gegenzug haben Sie Kopien auf jedem Entwicklungscomputer, wodurch Ihr Unternehmen möglicherweise gerettet wird, wenn Ihr zentrales Sicherungsschema eines Tages aus irgendeinem Grund fehlschlägt.

Es ist eine Frage der Priorität oder der Politik. Solange die Entscheidung absichtlich ist, wäre ich damit einverstanden.