In einer automatisierten Build- und Deployment-Pipeline hast du viel mit Versionsnummern zu tun. Bei Flownative folgen wir im Allgemeinen den Regeln der Semantischen Versionierung da dies ein weit verbreiteter Standard ist.
Einer der Vorteile der Verwendung eines solchen Standards ist, dass viele Tools gut zusammenarbeiten. Es gibt auch reguläre Ausdrücke mit denen du deine eigenen erfundenen Versionsnummern überprüfen kannst. Da es also einen Standard gibt und dein Tool behauptet, ihn zu unterstützen, sollte alles klar sein, oder?
In der Praxis gibt es ein paar Stolpersteine, die es zu beachten gilt. Einige der wichtigsten Tools und Plattformen, die wir verwenden, unterstützen nicht die gesamte SemVer-Syntax oder verhalten sich auf unerwartete Weise.
Hier ist ein kleiner Überblick darüber, was möglich ist und wie wir vorgehen:
Semantische Versionierung
Hier ist eine typische Versionsnummer nach dem Semantic Versioning Standard, erklärt:
1.21.4-beta1+9
| 1 | Major | Erhöhung, wenn die öffentliche API geändert wird |
| 21 | Minor | Erhöhung, wenn eine neue Funktion / Verbesserung aufgenommen wird |
| 4 | Patch | Erhöhung, wenn ein Fehler behoben wurde / eine nicht funktionale Änderung hinzugefügt wurde |
| beta1 | Vorabversion | Wird verwendet, wenn Vorabversionen zur Verfügung gestellt werden sollen (wir tun das selten) |
| 9 | Build | Erhöhen, wenn Nicht-App-Code / Konfiguration (z.B. für eine CI-Pipeline) geändert wird |
Git
Github verwendet gerne das Präfix "v" für Versionsnummern. Du magst argumentieren, dass dies hässlich oder unnötig ist (und wir würden wahrscheinlich zustimmen), aber es ist auch eine gängige Praxis, dies als Versionsnummer anzugeben. Es wird sogar im Semantic Versioning Standard als gängige Methode zur Bezeichnung von Versionen erwähnt.
Wenn wir uns an diese Konvention halten, wird das Leben ein bisschen einfacher, also sind wir gute Bürger und tun das (von jetzt an). Git-Tags, die wir verwenden könnten:
- v1.21.4+9
- v1.21.4+10
- v2.9.3 (wenn das Projekt sich nicht um die Build-Versionen kümmert)
In manchen Projekten führen wir Zweige ein, um mehrere Haupt- oder sogar Unterversionen gleichzeitig zu pflegen. Hier verwenden wir den Punkt "." als Trennzeichen, so dass die Namen der Zweige wie folgt aussehen:
- 1
- 2
- 7.3
Docker
Docker-Tags unterstützen nicht den gesamten Zeichensatz, der für Semantic Versioning benötigt wird. Es sind nur Buchstaben, Zahlen und ein Bindestrich erlaubt. Das bedeutet, dass "+" ein ungültiges Zeichen in Docker Image Tags ist. Deshalb taggen wir Builds normalerweise nicht einzeln, sondern überschreiben eine vorhergehende Version:
- v1.21.4+9 wird zu 1.21.4
- v1.21.4+10 wird ebenfalls zu 1.21.4
- v1.21.5+1 wird zu 1.21.5
Helm
Die Versionsnummern von Helm Charts richten sich eng nach dem SemVer-Standard. Das ist wichtig zu wissen, denn wenn du eine Helm-Installation oder ein Helm-Upgrade durchführst , werden standardmäßig nur stabile Versionen berücksichtigt. Das bedeutet, dass eine Version, die ein "-" enthält, nicht in der Liste der verfügbaren Kartenversionen erscheint, es sei denn, du gibst die Option --devel an. Das kann etwas verwirrend sein, wenn du einen Bindestrich für andere Zwecke verwendest (zum Beispiel als Präfix für Build-Nummern).
Wir müssen hier ein bisschen vorsichtig sein, denn obwohl das Helm-Diagramm die vollständige SemVer-Syntax verwendet, tun dies die Docker-Images, die es intern nutzt, nicht:
- 1.21.4+9 ist eine Helm-Chart-Version, die intern auf ein Docker-Image namens 1.21.4 verweist
Composer
Composer funktioniert auch mit SemVer einwandfrei. Und glücklicherweise kommt Composer auch mit dem Präfix "v" zurecht, das in Git-Tags vorkommt: Um die tatsächliche Version zu ermitteln, entfernt es das "v" aus dem Versionsstring.