Wir sind ein kleines Unternehmen mit mehreren Teams, die ihre eigenen Git-Repositories verwalten. Dies ist eine Webplattform und die Artefakte jedes Teams werden am Ende des Tages für nächtliche Tests bereitgestellt. Wir versuchen, den Prozess der Versionierung und des Packens zu formalisieren.
Jedes Team hat eine Hauptniederlassung, in der es sich täglich weiterentwickelt. Qualitätssicherungsmitglieder jedes Teams möchten, dass die Artefakte aus den Änderungen ihres Teams in einem Prüfstand bereitgestellt werden, in dem alle Komponenten vom Küchenchef kombiniert werden. Artefakte sind Tarballs, aber ich würde sie gerne in RPMs konvertieren, damit wir über Versionen richtig nachdenken und darüber nachdenken können.
Der Release-Prozess umfasst das Abschneiden eines Release-Zweigs vom Entwicklungszweig (in den meisten Fällen Master) der einzelnen Git-Repositorys. Diese werden dann an die Qualitätssicherung weitergeleitet, die Tests durchführt und eine Reihe von Artefakten abzeichnet.
Zum Beispiel ist dies ein typisches Git-Repository mit den dazugehörigen Release-Zweigen:
0-0-0-0-0-0-0-0-0-0 (master)
| |
0 0
(rel-1) |
0
(rel-2)
Ich versuche nicht, ein Schema für die Versionierung von Paketen aus Entwicklungszweigen zu finden. Wir möchten den Master-Zweig eines jeden Repos nicht übermäßig markieren und Tags darauf beschränken, nur Zweige freizugeben. Wir sollten jedoch in der Lage sein, die in den Testmaschinen bereitgestellten Pakete mit der Standard-Yum / RPM-Semantik abzufragen. Wie würden Entwicklungsversionen aussehen, wenn der Master-Zweig keine Tags hat? Ich verstehe, dass git describedies eine nützliche Darstellung einer Build-Version sein kann, aber dies funktioniert gut, wenn verschiedene Release-Punkte in der Verzweigung mit Tags versehen sind.
EDIT1: Als Antwort auf die Antwort von @ Urban48
Ich dachte mir, ich sollte unseren Release-Prozess ein bisschen näher erläutern. Für die Zwecke dieser Diskussion nehmen wir an, dass wir masterin allen Repositorys einen Zweig haben . Der masterZweig wird als Entwicklungszweig betrachtet und in einer automatisierten CI-CD-fähigen QA-Umgebung bereitgestellt. Hier werden einige nächtliche Tests durchgeführt, um die Stabilität des Masters sicherzustellen. Wir sehen uns diese Job-Pipeline an, bevor wir einen Release-Zweig kürzen. Unsere Veröffentlichungszweige sind kurzlebig. Angenommen, nach dem Ausschneiden eines Release-Zweigs (von einem stabilen Master) wird eine vollständige Regression ausgeführt, Korrekturen vorgenommen und für die Produktion bereitgestellt. Dies dauert ungefähr eine Woche. Wir geben fast alle zwei Wochen zur Produktion frei.
Unsere Feature-Zweige werden immer vom Master abgeschnitten und einigen Entwicklertests unterzogen, bevor sie mit dem Master zusammengeführt werden, bei denen sie den CI-CD-Stabilitätstests unterzogen werden.
Hotfixes werden in Hotfix-Zweigen (aus Versionszweigen herausgeschnitten) erstellt und mit minimalen Auswirkungstests in der Produktion bereitgestellt.
Unsere Versionsstrategie für Release- und Hotfix-Zweige folgt semver. Freigabezweige während des QS-Zyklus durchlaufen Versionen wiev2.0.0-rc1 , v2.0.0-rc2und werden schließlich nach QS-Abmeldung v2.0.0.
Wir machen manchmal gepunktete Releases für kleine Features, die zusammengeführt werden, um Zweige freizugeben (und dann zu meistern), in denen die Versionen werden v2.1.0 . Und Hotfixes übernehmen das v2.1.1Muster.
Es geht jedoch nicht darum, diese Zweige zu versionieren. Ich würde es vorziehen, dieses Versionsschema nicht komplett zu ändern. Die einzige Änderung ergibt sich für den Entwicklungszweig, d. H. Meister. Wie kann ich in der CI-CD-Umgebung zuverlässig angeben, welche Version für das vorherige Release in der Produktion vorhanden ist? Dies würde idealerweise durch Smart-Git-Tagging geschehen, aber etwas, das den Master-Zweig nicht übermäßig markiert, wird bevorzugt.
rcSuffix vorangehen ? Das würde die major.minorEntwicklungsversion bestimmen. rcund Build-Nummer kann nur auf dieser Basis erhalten werden. Auch rcauf Master macht das keinen Sinn, da wir uns nie vom Master lösen. Wir markieren unsere Veröffentlichungskandidaten heute in Veröffentlichungszweigen als Teil des Veröffentlichungszyklus
rcSuffix versehen.
