Git-Versionen als Build-Nummern integrieren oder nicht?

Ein Kollege und ich haben abwechselnd die Probleme und Vorzüge der Integration einer aus dem aktuellen Git-Repository abgeleiteten Version in unseren Code diskutiert.

Wir denken, die Vorzüge sind:

• Sie müssen sich beim Aktualisieren einer Versionsnummer keine Gedanken über menschliche Fehler machen
• Rückverfolgbarkeit zwischen dem, was wir in einem Gerät finden, und dem Quellcode, von dem es abgeleitet wurde

Folgende Probleme sind (für uns) aufgetreten:

• Von IDE abgeleitete Build-Systeme (z. B. MPLABX) können es schwierig machen, herauszufinden, wo diese Art von Hooks eingesetzt werden können (und es kann am Ende ziemlich kitschig werden)
• Mehr Arbeit, um dies tatsächlich in die Build-Skripte / Makefiles zu integrieren
• Die Kopplung an einen bestimmten Build-Ansatz (z. B. wenn eine Person mit XCode und die andere mit MPLABX erstellt) kann nachgelagerte Überraschungen verursachen

Wir sind also gespannt, wo andere in dieser Debatte gelandet sind. Es ist wirklich leicht für die Diskussion, anekdotisch zu werden. Es gibt viele Leute da draußen, die auf End-to-End-Automatisierung bestehen, die Menge an Vorarbeit und die damit verbundene Kopplung aufhängen. Und es gibt viele andere auf der anderen Seite der Debatte, die einfach das Einfachste tun, was funktioniert und mit den Risiken leben.

Gibt es eine begründete Antwort auf die Frage, auf welcher Seite man am besten landen kann?

Wir verwenden git describe mit Versions-Tags. Der Fluss ist im Grunde:

• Erstelle ein Tag für die Version, an der wir arbeiten (zB v1.1.2)
• Jeder Build wird ausgeführt git describe
• Wenn wir versenden, verwenden Sie den Tag-Namen

git describeGibt den Tag-Namen, die Anzahl der Festschreibungen seit dem Tag und den Hash des Tags an. Ein Beispiel-Tag sieht folgendermaßen aus:

v1.1.2-6-a3b27gae

Dies hat den Vorteil, dass Entwickler Hashes erhalten. Wenn also zwischen den Builds ein Fehler auftritt, kann der Entwickler die Änderungen leicht unterscheiden. Es ist auch blöd einfach zu handhaben; Lassen Sie einfach Ihren Teamleiter das Tag erstellen und auf einen neuen Bugfix-Zweig schieben, und Ihr Build-System kümmert sich um den Rest.

Wir entfernen den Hash (und die Build-Nummer), weil dies den Benutzern das Verständnis unserer Versionsnummern erleichtert. Wir stellen fest, dass dies uns das Beste aus beiden Welten bietet, während wir beim Entwickeln eines Releases immer noch genügend relevante Informationen liefern.

Derzeit haben wir eine etwas kompliziertere Version davon, aber die Idee bleibt.

Wir waren früher ein SVN-Shop, also war diese Berechnung einfach - die Build-Nummer war die SVN-Version und das war's. Wir haben versucht, dies aufrechtzuerhalten, als wir zu DCVSes gewechselt sind und festgestellt haben, dass dies aus mehreren Gründen fehlgeschlagen ist.

Erstens, wer weiß, ob Rev. 69bc333bc8d8 vor, nach oder gleichzeitig mit Rev. 25b0f0d1052c ist? Im Vergleich zum SVN-System gibt es sehr wenig Kontext, wenn Sie zumindest wussten, dass 101 nach 100 war. Zweitens macht die DCVS-Quellcodeverwaltung die Dinge in vielerlei Hinsicht nicht linear, wenn nachfolgende Builds möglicherweise nicht denselben Ball vorwärts bringen.

Wir haben uns schließlich dazu entschlossen, einen Build-Server zu verwenden, um Build-Nummern auf Dinge zu verteilen, da dieser die richtige Sichtbarkeit und Fähigkeit hatte, damit umzugehen.

Ich verwende das folgende Schema für ein visuelles Studio-Build-System einer C # -DLL, um automatisch Versionsnummern zu generieren (Wir hatten in der Vergangenheit Probleme mit nicht ordnungsgemäß durchgeführten Bereitstellungen, sodass eine saubere Methode zur Gewährleistung der Bereitstellung der richtigen Version erforderlich war).

• Major - Hardcoded 1, in der Regel von der Geschäftsseite bestimmt
• Minor - Hardcoded 0, in der Regel von der Geschäftsseite bestimmt
• Revision - Anzahl der Tage seit dem 1. Januar 2010 (oder einem anderen beliebigen Startdatum)
• Build - Die Hälfte der Sekunden seit Mitternacht (da es sich um eine vorzeichenlose 16-Bit-Zahl handelt)

Beachten Sie, dass dies voraussetzt, dass Sie 2 fungible 16-Bit-Zahlen ohne Vorzeichen zum Spielen haben. Es könnte auch ein äquivalentes System geschaffen werden, das kleinere Zahlen verwendet.

Beachten Sie auch, dass nicht numerische Felder hilfreich sein können, wenn Sie sie als Metadaten anhängen können. Fügen Sie beispielsweise die Git-Versionsnummer als Informationsversionsnummer hinzu.

Ich verbinde direkt die Ausgabe von Git Status, Log und Diff in die ausführbare Datei. Dann gibt es eine Option zum Drucken. Der Vorteil ist, dass Sie nicht nur herausfinden können, aus welchem ​​Zweig Ihre Binärdatei erstellt wurde, sondern auch, welche nicht festgeschriebenen Quellcodeänderungen enthalten sind. Bitte sehen Sie:

https://github.com/colding/MercuryFIX/tree/master/stdlib/scm_state

Sie sollten in der Lage sein, diese 3 Dateien zu verwenden, um Ihre eigene SCM-Statusbibliothek zu erstellen.

Ich würde die Verwendung von Autorevision empfehlen .

Sie können Ausgaben in verschiedenen Formaten erhalten, z. B. als C-Header .

Es gibt auch ein paar Beispiele (im Contributions-Verzeichnis), wie Sie die Dinge so anschließen können, dass unabhängig davon, wer sie erstellt und wie sie es tun, sie immer die gleichen Versionsinformationen erhalten, auch wenn sie aus einem Tarball erstellt werden.

Außerdem, da zusätzlich zu gitAutorevision mit svnund hges einfacher macht, von svn wegzuschalten, ohne zu viel ändern zu müssen, sobald Sie es eingerichtet haben.