Argumente gegen das Einchecken von Binärdateien in SCMs

Ich arbeite für ein Unternehmen, das hauptsächlich Java-Anwendungen erstellt, und ich versuche, alle davon zu überzeugen, keine Binärdateien (Abhängigkeiten und Endprodukte) mehr in SCM einzuchecken.

Sie wissen, dass es eine schlechte Praxis ist, aber sie denken, dass "es funktioniert" und es ist nicht wirklich ein Problem, selbst wenn viele Leute über Maven und andere Werkzeuge zum Bauen neben Ant Bescheid wissen. Sowohl PMs als auch Programmierer (ca. 50 Personen) sind bereit, sich jedes Argument anzuhören und sogar anzuerkennen, dass es eine Verschwendung von Backup-Speicherplatz ist, aber ich möchte wirklich überzeugen, da die Änderung der Gewohnheit viel Aufwand bedeuten würde. Welche Argumente verwenden Sie, um eine Änderung zu unterstützen?

Bearbeiten: Okay, es ist sinnvoll, zwischen Dateien, die sich fast nicht ändern, wie Abhängigkeiten, und generierten Dateien zu unterscheiden. Trotzdem interessieren mich Gründe gegen Letzteres.

Speicherplatz ist billig, und das ist kein sehr überzeugendes Argument dafür, warum Sie Dateien einchecken sollten oder nicht.

Stattdessen können Sie sich an den Zweck von SCM wenden. Jede Datei, die von SCM verfolgt wird, muss die parallelen, verteilten Änderungen verwalten, die Ihr Team vornimmt. Nichts davon ist wirklich offensichtlich, bis zwei Teammitglieder versuchen, dieselbe Datei zu ändern. Das Auflösen dieser Änderungen ist das eigentliche Ziel von SCM, um ein versehentliches Überschreiben der Arbeit eines anderen Entwicklers zu verhindern und hoffentlich den Prozess des Zusammenführens dieser Änderungen zu automatisieren.

Das Zusammenführen von Binärdateien ist normalerweise eine echte Herausforderung, da es für ein generisches Zusammenführungswerkzeug keine vernünftige Möglichkeit gibt, zu erraten, wie eine zusammengeführte Binärdatei funktionieren soll. Es kann nicht genug darüber wissen, wie die Indizes oder Versatzzeiger in der Datei funktionieren, es sei denn, es wurde speziell entwickelt, um diesen bestimmten Dateityp zu erkennen.

Das heißt, es liegt an dem Entwickler, die Binärdatei von Hand zusammenzuführen und dem SCM dann mitzuteilen, dass die Datei so zusammengeführt wurde. Da es sich um einen Entwickler handelt, deckt die Zusammenführung möglicherweise nicht alle Änderungen der beiden vorherigen Eincheckvorgänge ab. Da die Datei binär ist, gibt es keine automatisierte Möglichkeit, die Zusammenführung zu überprüfen.

Für binäre Formate, die wirklich Projektquellen darstellen, wie z. B. Kunstobjekte, ist dies ein unglücklicher, aber notwendiger Schritt. Build-Ausgaben sind jedoch keine Quellen. Sie müssen nicht zusammengeführt werden, da die Quellen zusammengeführt und eine resultierende Build-Ausgabe neu generiert werden kann. Das Verfolgen und Verwalten dieser Änderungen ist zu 100% Verschwendung. Es verschwendet die Ressourcen des SCM, wenn auch nicht besonders viel, aber es verschwendet auch Entwicklerzeit, um die falschen Zusammenführungsfehler zu überwinden. Entwicklerzeit ist sehr teuer und alles, was sie verschwendet, ist Krebs.

Andererseits gibt es einen bestimmten Fall, in dem die Build-Ausgaben archiviert werden sollten. Jede Version des Projekts, die jemals ausgeliefert oder bereitgestellt wurde, sollte wahrscheinlich auf unbestimmte Zeit beibehalten werden. Wenn Sie eine genaue Byte-für-Byte-Kopie des tatsächlichen Builds haben, mit dem ein Kunde Probleme hat, kann dies die Unterstützung dieses Kunden erheblich vereinfachen, da Sie über die genaue Version verfügen, die er hat.

Diese Sicherung sollte sich wahrscheinlich nicht im selben Repository wie der Quellcode befinden, da sie im Allgemeinen unterschiedlichen Zeitplänen folgen und grundsätzlich unterschiedliche Strukturen aufweisen.

Abhängigkeiten, auch in binärer Form, sollten eingecheckt werden, damit es einfach funktioniert, wenn jemand anderes das Projekt herunterfährt. Das Hauptanliegen ist nicht der Dateityp, sondern wie die Datei erstellt wird. Als Faustregel verwende ich, dass wenn es mit einer anderen Datei generiert werden kann, es nicht eingecheckt wird - dies bedeutet automatisch generierte Dokumentation, von mir erstellte Binärdateien usw.

Einer der Hauptvorteile der Verwendung von SCMs besteht darin, dass Sie Ihr System jederzeit in der Vergangenheit rekonstruieren können. Es macht also keinen Sinn, Ihren endgültigen Build in Ihrem SCM zu speichern, da Sie einfach die Versionsnummer überprüfen und erstellen können.

Sie erwähnen Abhängigkeiten ... Ihr SCM sollte so eingerichtet sein, dass Sie einen sauberen Checkout auf einem neuen Computer (mit Entwicklungsumgebung) durchführen, auf Build klicken und in der Lage sein sollten, Ihr System zu erstellen, ohne etwas anderes installieren zu müssen. Daher ist es eine gute Idee, binäre Abhängigkeiten in Ihrem SCM beizubehalten. Bibliotheken ändern sich selten, sodass sie nicht viel Platz beanspruchen.

Fast niemand macht das.

Scheint überflüssig, sowohl Quell- als auch Objektdateien einzuschließen (Quelldateien sind offensichtlich erforderlich). Die Objektdateien sind nicht nur unnötig, sondern können auch viel Platz beanspruchen. Wenn Ihre Firma ein verteiltes SCM (Git, Hg, Bzr) verwendet, müssen diese Binärdateien kopiert und unter allen Entwicklern gespeichert werden.