Was ist der beste Weg, um ein Mehrkomponentenprojekt zu versionieren?

Ich habe ein Programm, das aus 5 Hauptkomponenten besteht. Ich finde die Standardversionsnummerierung zu einschränkend, weil ich sehen möchte, auf welcher Version sich die einzelnen Komponenten befinden.

Hat jemand einen einfachen Weg gefunden, dies zu tun, außer jedes einzeln aufzulisten?

Wir haben genau das gleiche Problem mit unserem Produkt und haben beschlossen, für jede Komponente individuelle Versionsnummern zu erstellen. Die Produktversion ist nur eine Marketingversion, die sich bei einer bestimmten Überarbeitung aus den verschiedenen Komponenten zusammensetzt.

Wir haben eine "Systemversion", eine Standardversionsnummer, die eine bestimmte Konfiguration von Komponenten beschreibt. In einer separaten Datei werden die einzelnen Komponentenversionen für diese bestimmte Systemversion aufgelistet. Kunden sagen 5.2.1, aber wir können bei Bedarf den einzelnen Build nachschlagen. Normalerweise synchronisieren wir für eine Hauptversion alle einzelnen Versionen, damit alles wieder aus derselben Filialnummer aufgebaut wird.

Die Versionierung ist ein Problem, das von der komponentenbasierten Anwendungsentwicklung getrennt ist. Entweder möchten Sie jede Komponente versionieren oder Sie möchten die gesamte Anwendung versionieren.

Ein bekanntes Versionsmuster stammt von Microsoft :

major version.minor version.build number.revision

Beispielsweise können Sie sehen, dass die DLL-Dateien in der .NET-Plattform Versionen wie 2.0.3600.1 oder ähnliches haben.

Ich empfehle daher, zunächst festzulegen, ob Sie das gesamte System oder seine Komponenten versionieren möchten. Wenn Sie das gesamte System versionieren möchten, erstellen Sie nach jeder Integration das gesamte Projekt und erhöhen Sie den Teil der Build-Nummer . Wenn nicht, versionieren Sie einfach jede Komponente beim Erstellen.

Sei vorsichtig mit der Versionierung, es könnte dich umbringen :-) Versuche nicht, die Dinge zu kompliziert zu machen.

Ich denke, der folgende Ansatz könnte Ihnen helfen:

Versionieren Sie jede Komponente einzeln mit dem gewünschten Versionsschema. Aus Ihren Kommentaren geht hervor, dass Sie über ein VCS verfügen. Ich gehe auch davon aus, dass jede Komponente eine Datei hat, in der ihre Version gespeichert ist (richtig?). Fügen Sie einmal pro Tag / Woche (je nachdem, was für Ihr Team besser funktioniert) einer der neuesten Revisionen in VCS ein Tag hinzu, das diese Revision als die letzte offizielle Revision kennzeichnet (und optional eine Super-Revisionsnummer erhöht). Jetzt können Sie das VCS nach den Revisionen mit diesem Tag abfragen und dann nach der Version der Komponenten in diesem offiziellen Build suchen.

Wenn Sie nur lokal möchten, schreiben Sie ein kleines Skript, das die Version jeder Komponente an der Stelle zusammenfasst, an der sie im Code gespeichert ist.

Wenn Sie es noch schicker machen möchten, können Sie nach dem Markieren die zu jeder Komponente gehörenden Dateien anzeigen, wobei Sie berücksichtigen können, dass Sie die Dateien identifizieren können, die zu einer bestimmten Komponente gehören. Wenn sich etwas ändert, erhöhen Sie die Version für diese bestimmte Komponente. Die Alternative besteht darin, dies manuell zu tun. Eine weitere Alternative ist eine Kombination aus Verzweigung und Zusammenführung mit Versionsverfolgung.

Die meisten Versionsnummern verwenden eine größere und eine kleinere Revision, die vom Marketing gesteuert wird. Daher können Sie diese nicht zum Verfolgen einzelner Komponentenversionen verwenden. Kurz gesagt, Sie müssen einen anderen Teil der Version finden, den Sie zum Verfolgen von Versionen einzelner Komponenten verwenden können, und die Haupt- und Nebenversionsnummern für das Verfolgen des gesamten Pakets reservieren.

Wenn Sie dem Microsoft-Muster folgen:

major-version.minor-version.build-number.revision

Sie können die .revision verwenden, um die Version jeder einzelnen Komponente zu verfolgen, und die kleinen und großen Revisionsnummern verwenden, um eine vollständige Produktänderung auf die übliche Weise zu verfolgen.

Wenn Sie einem ähnlichen Muster folgen:

Major-Version.Minor-Version.Build-Number

Sie müssen die Build-Nummer verwenden, um die einzelnen Komponentenversionen zu verfolgen.

Ganze Bücher sind über Versionierungssoftware geschrieben.

Hier ist ein Ansatz, den ich verwende.

Jeder Teil hat eine Version in der Form:

major.minor.developmental

Jedes davon ist eine Zahl, die bei 0 beginnt.

Für eine formelle Freigabe (dh für Kunden) muss der Entwicklungsteil aus politischen Gründen immer 0 sein.

Major wird durch Marketingentscheidung erhöht.

Minor wird durch die Veröffentlichung von Funktionssätzen erhöht - auf den Markt.

Beispiel:

• Ich beginne mit der Entwicklung einer neuen Komponente, daher lautet meine Versionsnummer 0.0.1. Wenn ich meinen Schreibtisch beispielsweise für interne Tests an meine Kollegen weitergebe, steigt die Entwicklungsnummer auf 0.0.2, 0.0.3 usw.

• Ich veröffentliche diese neue Sache als 1.0.0 auf den Markt, wobei die einzige zulässige Änderung vom Ende der Entwicklung bis zur Veröffentlichung darin bestand, die Versionsnummer zu ändern (z. B. 0.0.43 -> 1.0.0).

• Einige neue Funktionen sollen hinzugefügt werden. Ich beginne mit der Arbeit an der 1.0.0-Baseline und füge diese Funktionen hinzu. Daher sind die Versionen, die ich meinen Kollegen zum Testen freigebe, 1.0.1, 1.0.2 usw.

• Die nächsten Funktionen werden als 1.1.0 auf den Markt gebracht.

• Das Marketing entscheidet, dass das nächste große Ding wirklich groß sein wird, also wird es als 2.0.0 veröffentlicht. Ich beginne mit der Arbeit an 1.1.1, fahre mit 1.1.x fort und veröffentliche als 2.0.0.

Und so wiederholt sich der Zyklus.

Dieser Ansatz gibt Ihnen für jede Komponente die Rückverfolgbarkeit der Abstammung.

Verwenden Sie innerhalb Ihres Revisionsverwaltungssystems für Quelle (und Objekt) Zweige und Tags (Beschriftungen, unabhängig von Ihrer heutigen Terminologie), um die Entwicklung zu verwalten.

Ihre Revisionskontrolle kann dann jede Komponente vollständig separat verwalten, mit Entwicklungszweigen und Labels / Tags für jede. Oder Sie können sie alle zusammen bündeln. In diesem Fall möchten Sie möglicherweise nach Arbeitspaketen verzweigen. Achten Sie jedoch darauf, dass Sie die einzelnen Komponenten freigeben / kennzeichnen (und wenn Sie dies tun, beschriften / kennzeichnen Sie alles, nicht nur die Bits für das Auf diese Weise haben Sie eine Momentaufnahme des aktuellen Zustands von allem.)

Es ist wahrscheinlich, dass Ihr Veröffentlichungsprozess sorgfältige Überlegungen erfordert. Die Verwendung dieses Ansatzes umfasst einige manuelle Schritte, die möglicherweise unerwünscht sind. Dies hängt alles davon ab, wie Ihr Build-System die Versionsnummern in das endgültige Objekt einfügt. Für viel eingebetteten Code, bei dem die Versionsnummern nur benannte Nummern sind (z. B. #definiert in C-Code), haben Sie keine andere Wahl, als dies alles manuell zu tun. Desktop-Plattformen mit netten GUIs machen dies oft viel freundlicher.

Zusammenfassung

Für mich besteht die einzige zuverlässige Möglichkeit zur Versionssoftware darin, die Hash- oder Änderungssatzkennung Ihres Versionskontrollsystems zu verwenden.

Eine allgemeine Versionsnummer des Builds kann nützlich sein, ist jedoch nur dann wirklich eindeutig, wenn Sie über einen Build-Server verfügen und / oder jede Version signieren. Für viele von uns ist dies jedoch einfach nicht realisierbar.

Wenn Ihr Projekt auf mehrere Versionskontroll-Repositorys aufgeteilt ist, müssen Sie auch einen Mechanismus erstellen, mit dem Ihre Benutzeroberfläche jedes abhängige Repository abfragen und den Hash an den Benutzer zurückmelden kann.

Beispiel aus persönlicher Erfahrung

In einem Projekt bei einem früheren Arbeitgeber, bei dem wir Probleme mit unserer (internen) Kundenmodifizierungssoftware hatten und diese neu kompilierten, habe ich einen Prozess eingeleitet, bei dem die Quecksilber-Hashes in jede Anwendung und Bibliothek kompiliert wurden. Bei jedem Start der Software wurde eine Abfragezeichenfolge erstellt, indem alle Softwarekomponenten abgefragt wurden.

Diese Revisionszeichenfolge wurde angezeigt, als Sie zur Info-Seite gingen, und wurde bei jedem Start der Anwendung in die Protokolldatei geschrieben. Es hatte die Form:

Application name     (6a72e7c61f54)
    Library1         (b672a13a41e1)
        Library2     (9cc35769b23a)
    Library2         (9cc35769b23a)
    Library3         (4e9f56a0186a+)
        Library2     (9cc35769b23a)
    Library4         (2e3b08c4ac76)
        Library1     (b672a13a41e1)
            Library2 (9cc35769b23a)

Daran konnte ich leicht erkennen, dass sie Library3 geändert und diese Änderungen nicht in das Repository übernommen hatten, sodass sie Code verwenden, der nicht kontrolliert wird. Ich könnte die Hashes auch mit meinem aktuellen Testsystem vergleichen, um festzustellen, dass sie Library1 auf eine ältere Version zurückgesetzt haben.

Dies bedeutete, dass ich immer dann, wenn ein Fehler gemeldet wurde, genau den Code neu erstellen konnte, der zum Zeitpunkt des Problems verwendet wurde, oder zumindest mit Sicherheit wusste, dass ich das Setup nicht reproduzieren konnte.

Weitere Informationen zu dem von mir verwendeten Build-System, wie ich dies erreicht habe, welche Probleme ich hatte und was die Leute vorgeschlagen haben, um sie zu vermeiden, finden Sie in meiner Frage zum Stapelüberlauf .

Hinweis: Dieses System ist nur dann wirklich funktionsfähig, wenn Sie ein Revisionskontrollsystem verwenden, bei dem ein bestimmter Hash garantiert zu demselben Satz von Dateien in Ihrem Arbeitsverzeichnis führt (z. B. Git und Mercurial), wenn ein bestimmtes Arbeitsverzeichnis eine Mischung von Dateien enthalten kann und Verzeichnisse aus mehreren Revisionen (z. B. svn), dann sind alle Wetten bezüglich des Status des Arbeitsverzeichnisses deaktiviert und diese Methode funktioniert überhaupt nicht.