Wir haben ein Jira-Projekt, das alle Vorgänge für eine einzelne Website enthält. Die Website hat mehrere verschiedene Komponenten, wie das Thema und mehrere Lambda-Funktionen. Jede Komponente hat ihr eigenes Repository und wird getrennt von den anderen bereitgestellt.
Verwirrung entsteht, wenn man versucht herauszufinden, wie man jede Jira-Version/-Version benennen soll. Wir werden semantische Versionierung verwenden, aber erstellen wir für jede Komponente eine andere Version? Sollte beispielsweise eine Versionshistorie für ein Projekt wie folgt aussehen:
Oder sollten alle Komponenten dieselbe Release-Version haben?
Auch eine verwandte Frage: Sollte die Repository-Version mit der Jira-Version übereinstimmen?
Die Antwort auf diese Frage hängt am Ende davon ab, wie Sie diese Informationen verwenden werden. Warum gibt es überhaupt Versionen? Sie müssen darüber nachdenken, bevor Sie fragen, wie Versionen verwaltet werden sollen.
Denken Sie etwas länger nach. Erhalten Sie die Antwort.
Habe es? OK.
(Haftungsausschluss ... diese Antwort entspricht möglicherweise NICHT Ihren Anforderungen)
Aus Sicht des Projektmanagements möchten Sie normalerweise wissen, was wann freigegeben wurde . Wenn Sie ein „Release“ als Version verstehen, die Ihre Anwendung zu einem bestimmten Zeitpunkt hatte , ist es sinnvoll, Releases komponentenunabhängig zu haben.
In meinem Projekt haben wir jede Woche mehr als 90 Komponenten und UAT-Releases – nach ein paar Zyklen gehen sie an PROD. Wie verfolgen wir sie? Es gibt eine wöchentliche Release-ID, und wir haben (ja, ich weiß, es klingt umständlich) einen Confluence -Eintrag, in dem wir alle komponentenspezifischen Versionen auflisten, die in diesem Release vorhanden sind ... und in diesem Punkt weicht unser Ansatz von dem einen ab von Alexey vorgeschlagen, da jede Komponente unabhängig von der Version eine bestimmte Build-Nummer hat.
Unser Confluence würde so aussehen (in Fettdruck ändert sich die Komponente bei jeder Iteration):
Version 1.0.0:
Version 1.0.1:
Version 1.0.2:
Ich bin seit Jahren denselben Umständen ausgesetzt. Und der Ansatz, die Versionen für jede bestimmte Komponente zu haben, zeigte aufgrund von Jira-spezifisch eine schlechte Effizienz (zumindest in meinem Projekt).
Die Jira-Versionierung ist gut konzipiert, wenn Sie das Projekt als Ganzes versionieren, und unterstützt keine Komponentenversionierung. Die beste Lösung besteht also darin, eine Migration zu anderen Aufgabenverwaltungssystemen in Betracht zu ziehen oder die Verwaltung der Komponenten jeweils in einem separaten Projekt in Erwägung zu ziehen.
Ihr Ansatz wäre in Ordnung, es sei denn, Sie haben eine mehr oder weniger große Veröffentlichungshistorie. Je mehr Veröffentlichungen Sie abschließen, desto mehr Schwierigkeiten werden Sie haben, wenn Sie die Dinge analysieren müssen, die in einem ziemlich großen Umfang erledigt wurden.
Repository-Versionen sollten mit den Jira-Versionen übereinstimmen. Auf diese Weise können Sie leicht auf ein geeignetes eingebautes Repo verweisen, das die Version eines Elements aus Jira enthält, und umgekehrt.
Eine Version ist ein Produkt, das von Benutzern verwendet wird. Wenn die Komponenten in Ihrer Version einzeln veröffentlicht werden können, ziehen Sie mehrere Versionen in Betracht. Andernfalls handelt es sich um eine Veröffentlichung eines einzelnen Produkts mit Details zu einer Reihe von Änderungen.
Veröffentlichungen sind mit Kosten verbunden; Releases zu häufig und Ihre Benutzer werden sich lösen, wenn sie von all dem Lärm um Releases überwältigt werden. Wenn Sie nicht häufig genug loslassen, besteht die Gefahr, dass Sie sich aufgrund des wahrgenommenen Mangels an Fortschritten lösen.
Ein Product Owner sollte über Nutzungsmetriken und/oder Hypothesen verfügen, die das Engagement der Benutzer im Laufe der Zeit messen können; Veröffentlichungen zeigen Deltas in der Benutzerinteraktion – Erhöhungen insgesamt, Verschiebungen von älteren Funktionen zu neuen Funktionen oder insgesamt reduziert.
Arbeiten Sie mit dem Product Owner zusammen, um die richtige Kadenz für die Veröffentlichung zu bestimmen.
Sobald Sie die Häufigkeit und Art der Veröffentlichungen verstanden haben, wird es klar sein, wie man sie nennt. In der Zwischenzeit ist Product-Major-Minor ausreichend.
Gürkan Cetin
Thiago Cardoso