Ist es empfehlenswert, Softwareversionsnummern in VCS zu speichern?

Eine Produktversion wie z. B. v1.0.0.100stellt nicht nur eine einzigartige Produktionsversion von Software dar, sondern hilft auch bei der Identifizierung von Funktionssätzen und Hotfix-Phasen für dieses Produkt. Im Moment sehe ich zwei Möglichkeiten, die endgültige Paket- / Build- / Binärversion eines Produkts zu pflegen:

Versionskontrolle. Eine Datei speichert irgendwo die Versionsnummer. Der Build-Server für Continuous Integration (CI) verfügt über ein Skript zum Erstellen der Software, das diese eingecheckte Versionsnummer verwendet, um sie auf alle Bereiche der benötigten Software anzuwenden (Binärdateien, Installationspakete, Hilfeseiten, Dokumentation usw.).
Umgebungsparameter und / oder Build-Parameter. Diese werden außerhalb der Versionskontrolle verwaltet (dh sie sind nicht an den Snapshot / Tag / Zweig gebunden). Die Erstellungsskripte verteilen und verwenden die Zahl auf die gleiche Weise, erhalten den Wert jedoch nur unterschiedlich (sie werden dem Erstellungsskript zur Verfügung gestellt, anstatt dem Skript mitzuteilen, wo sie relativ zum Quellbaum abgerufen werden sollen).

Das Problem beim ersten Ansatz besteht darin, dass Zusammenführungen über Hauptleitungszweige hinweg kompliziert werden können. Wenn Sie immer noch zwei parallele Versionen derselben Software verwalten, werden Konflikte beim Zusammenführen der beiden Hauptversionen behoben, wenn sich die Version auf beiden seit der letzten Zusammenführung geändert hat.

Das Problem beim zweiten Ansatz ist die Versöhnung. Wenn Sie vor einem Jahr zu einem Release zurückkehren, verlassen Sie sich ausschließlich auf die Tag-Informationen, um dessen Release-Nummer zu identifizieren.

In beiden Fällen gibt es möglicherweise bestimmte Aspekte der Versionsnummer, die vor der CI-Erstellung nicht bekannt waren. Zum Beispiel kann ein CI-Build programmgesteuert eine vierte Komponente einfügen, bei der es sich tatsächlich um die automatisierte Build-Nummer handelt (z. B. 140. Build für den Zweig). Es kann sich auch um eine Versionsnummer in VCS handeln.

Was ist der beste Weg, um mit der Versionsnummer einer Software Schritt zu halten? Sollen die "bekannten" Teile immer in VCS gepflegt werden? Und wenn ja, sind die Konflikte zwischen den Hauptniederlassungen ein Problem?

Im Moment pflegen wir unsere Versionsnummer über Parameter, die im CI-Build-Plan (Atlassian Bamboo) angegeben und gepflegt sind. Wir müssen vor dem Zusammenführen in unserer masterFiliale darauf achten, dass die Versionsnummern vor dem Start des CI-Builds ordnungsgemäß eingerichtet werden . In Bezug auf den Gitflow-Workflow bin ich der Meinung, dass wir, wenn die Versionsnummer in der Quellcodeverwaltung nachverfolgt würde, garantieren könnten, dass sie ordnungsgemäß eingerichtet ist, wenn wir unseren releaseZweig in Vorbereitung auf die Veröffentlichung erstellen . Die Qualitätssicherung würde einen abschließenden Integrationstest / Rauch- / Regressionstest für diesen Zweig durchführen und nach dem Signoff findet eine Zusammenführung masterstatt, die die Verpflichtung zur Freigabe signalisiert.

— void.pointer
quelle

Ist ein Zusammenführungskonflikt zwischen zwei Versionen einer Datei, version.txtin der eine Version die einzelne Zeile 1.0.7und die andere enthält, 1.2.0wirklich so schwer zu lösen? Wenn dies der einzige Konflikt ist, bei dem zwei Zweige zusammengeführt werden, würde ich mich als sehr glücklich schätzen. Wie oft kommt es vor? Ist es nicht gut, dass Sie gezwungen sind, sich zu überlegen, welche Versionsnummer die zusammengeführte Version haben sollte, wenn dies der Fall ist ? (Entschuldigen Sie die mehrdeutige Verwendung des Wortes "Version".)

— 5gon12eder

@ 5gon12eder Die Schwierigkeiten oder Gefühle bei der Zusammenführung selbst sind irrelevant. Es ist nur ein negativer Aspekt der Gesamtlösung.

— void.pointer

Antworten:

Persönlich wähle ich Option 3: Versionsinformationen in VCS- Metadaten , insbesondere Tags, beibehalten.

Git macht dies sehr einfach, da es einen Befehl gibt git describe, der ein Commit basierend auf einem Tag eindeutig beschreiben kann. So funktioniert das:

Wenn das aktuelle Commit markiert ist, geben Sie den Namen des Tags aus.
Ansonsten geht die Geschichte zurück , bis Sie einen Tag finden und Ausgang dann eine Beschreibung in folgendem Format: <tag>-<number of commits since the tag>-g<abbreviated commit hash>.
Wenn der Arbeitsbaum nicht festgeschriebene Änderungen enthält, fügen Sie diese an -dirty.

Wenn Sie also eine Release-Erstellung durchführen und das Commit markiert haben 1.2.3, wird es ausgegeben 1.2.3. Wenn Sie derzeit an 1.2.4 arbeiten und seit 1.2.3 4 Commits durchgeführt haben und nicht festgeschriebene Änderungen in der Struktur haben, wird diese ausgegeben 1.2.3-4-gdeadbee-dirty.

Dies ist garantiert einzigartig und monoton sowie für den Menschen lesbar und kann daher direkt als Versionszeichenfolge verwendet werden. Das einzige, was Sie sicherstellen müssen, ist eine korrekte Benennungskonvention für Tags.

— Jörg W. Mittag
quelle

Ich liebe diese Idee wirklich, aber mit JIRA + Bamboo scheint dies schwierig zu bewerkstelligen. Bamboo funktioniert nur in Zweigen, nicht in Tags. Sie müssen also sicherstellen, dass ein Tag gepusht wird, bevor ein Build generiert wird. Dies ist fehleranfällig.

— void.pointer

git describefunktioniert auch mit Zweigen: " --all - Verwenden Sie anstelle der mit Anmerkungen versehenen Tags einen beliebigen Verweis im refs/Namespace. Mit dieser Option können bekannte Zweige, Zweigstellen mit Fernverfolgung oder Lightweight-Tags abgeglichen werden." Ich bin mir jedoch nicht sicher, wie das mit Bamboo funktioniert. (Dies erfordert natürlich eine sorgfältige Benennung der Zweige, genau wie dies im normalen Modus bei Tags der Fall ist.)

— Jörg W Mittag,

Ich kenne einige Leute, die vollautomatische Releases von Git machen. Die Versionszeichenfolge wird von erstellt git describe, das Änderungsprotokoll wird von git shortlog(also tatsächlich von einem Skript, das die Ausgabe analysiert git log --pretty=tformat:<some custom format string>) generiert, und die Versionshinweise werden aus der Tag-Beschreibung generiert und git notesan wichtige Meilenstein-Commits angehängt.

— Jörg W Mittag

Mein Punkt ist, dass das Etikett erstellt werden müßte im Vorfeld der Veröffentlichung , so dass Commits , nachdem sie ordnungsgemäß mit einer Basenzahl versioniert werden. Dies widerspricht dem Prinzip der Kennzeichnung während oder zum Zeitpunkt der Veröffentlichung. Bamboo übernimmt Builds automatisch basierend auf Commits zu master(von develop, denke daran, dass ich gitflow verwende). Was passiert, wenn jemand eine Zusammenführung masterohne Tag vornimmt? Es wird nicht die richtige Version verwenden (in der Tat würde es die Version der letzten Veröffentlichung verwenden)

— void.pointer

Wenn Sie ein Schema wie folgt verwenden, Tagging ist die Freigabe. Ah, ich verstehe, worauf du hinaus willst, denke ich. Derzeit ist Ihr CI-Server der Release-Treiber, und mit dieser Änderung ist der SCM der Release-Treiber, aber Sie möchten, dass dies auch so bleibt?

— Jörg W Mittag

Ja. Es wird empfohlen, den größten Teil der Versionsnummer in vcs zu speichern. Wenn wir die semantische Versionierung von semver.org in Betracht ziehen, bei der major.minor.patch.build vorhanden ist, müssen die ersten drei in vcs leben. Die letzte kann eine inkrementelle Zahl von Ihrem Build-Server sein, die verwendet wird, um das spezifische Commit, aus dem eine Binärdatei besteht, zurückzuverfolgen.

Um dies in .NET zu vereinfachen, haben wir eine kleine cmd-Zeilen-Exe erstellt, die an git übergeben wird. Bei einem Pre-Build-Ereignis wird die Build-Nummer abgerufen, die teamcity während des Builds markiert hat. Dieses Cmd-Linien-Tool generiert automatisch eine Klasse mit einer Konstanten, die die Build-Nummer enthält. Der Rest der Versionsnummer: major.minor.patch ist nur eine normale Konstante in einer anderen Datei. Diese beiden gemeinsam genutzten Dateien sind in jeder Baugruppe in einer Lösung als Verknüpfung enthalten (Alt + Umschalt + Ziehen).

Dieser Ansatz ist leistungsstark genug, um Teamfähigkeit zu erlangen und unseren Code zu testen. Push to Azure und lassen Kudu es erneut erstellen, aber mit der teamcity Build-Nummer als die Version der DLLs.

— Esben Skov Pedersen
quelle