Orbit-Versionen

The Releases tab turns your git tags into a version history you can read: every tagged deployment, in order, with its commit, its author, its status and a link straight to the tag in your repository.

Auf der Registerkarte "Releases" werden deine Git-Tags in eine Versionshistorie umgewandelt, die du lesen kannst: jede markierte Bereitstellung in Reihenfolge mit ihrem Commit, ihrem Autor, ihrem Status und einem direkten Link zum Tag in deinem Repository.

Wo sich Releases befindet

Öffne Orbit, klicke auf das Projekt und wähle Releases unter der Gruppe Deployments im Projektregisterkarten-Strip. Die Seite heißt Releases und beschreibt sich selbst als Tag-basierte Deployments: Ein Release wird erstellt, wenn ein Git-Tag deinem Tag-Pattern entspricht.

Die benachbarte Registerkarte Deployments listet jeden Build auf, markiert oder nicht. Releases ist die gefilterte Ansicht: nur diejenigen, die du als Version markiert hast.

Das Tag-Pattern einstellen

Releases beginnen mit einem Pattern. Öffne Settings, finde die Karte Git tag deploys und gib einen glob wie v* oder release-* ein. Wenn du sie leer lässt, werden Tag-Deployments vollständig deaktiviert, weshalb der Platzhalter des Feldes v* (disabled) lautet.

Mit einem eingestellten Pattern löst das Pushen eines passenden Tags ein Deployment in die Production aus und speichert das Ergebnis als Release. Ohne ein Pattern zeigt die Registerkarte Releases einen leeren Zustand, der dich auffordert, einen Tag zu pushen und ein Pattern in Settings einzustellen.

Ein Tag-Pattern gibt dir einen zweiten, expliziten Weg zur Production neben Pushes zum Production-Branch. Teams, die möchten, dass Deployments ein bewusster Akt sind und nicht eine Nebenwirkung des Zusammenführens, schalten oft die automatische Branch-Bereitstellung aus und führen die Production nur über Tags.

Ein Release erstellen

Der gesamte Workflow von deiner Seite sind zwei Git-Befehle:

git tag -a v1.4.0 -m "Checkout flow rebuild"
git push origin v1.4.0

Orbit empfängt den Tag, vergleicht ihn mit deinem Pattern, deployed den getaggten Commit in die Production und speichert einen Release. Er wird auf dieser Registerkarte mit einem Badge Building angezeigt und wechselt zu Deployed, wenn er ankommt, oder zu Failed, wenn der Build fehlgeschlagen ist.

Verwende annotierte Tags statt leichter. Ein annotierter Tag enthält eine Nachricht, einen Autor und ein Datum, die alle im Release landen.

Ein vorhandenes Deployment taggen

Du musst keinen Git-Tag pushen, um einen Release zu erhalten. Jedes Deployment kann von seiner Detailseite aus getaggt werden, und ein Tag, der wie eine Versionsnummer aussieht, wird hier aufgegriffen.

Ein versionsförmiger Tag ist einer wie 1.4, 1.4.0, v1.4.0 oder v2.0.0-rc1. Alles andere bleibt ein einfaches Deployment-Tag und erstellt keinen Release-Eintrag.

Dies ist die Notfalllösung für den Fall, dass ein Release ausgegangen ist, bevor du das Pattern eingestellt hast, oder wenn ein Hotfix von Hand bereitgestellt wurde und du ihn sowieso in der Versionshistorie haben möchtest.

Ein Release lesen

Jede Release-Zeile zeigt:

Das Tag als Titel des Release.
Den Commit und seine Nachricht.
Den Autor, angezeigt als by name.
Die Umgebung, in die es ging, farbcodiert nach Typ.
Ein Status-Badge: Deployed, Building oder Failed.
Ein Link View on zum Tag in deinem Repository.
Ein Link zur zugrunde liegenden Bereitstellung.

Der Link View on zeigt auf die richtige Stelle pro Anbieter: die Releases-Seite auf GitHub, die Tag-Seite auf GitLab oder die Quelle bei diesem Tag auf Bitbucket.

Release Notes

Wenn du einen Release in deinem Repository für einen Tag veröffentlichst, werden die Notizen herübergezogen und an das Deployment angehängt, sodass die Registerkarte Releases denselben Text enthält, den du in deinem Repository geschrieben hast, anstatt dass du zwei Kopien führen musst.

Das macht das Repository zum einzigen Ort, um Release Notes zu schreiben. Schreibe sie einmal, dort wo deine Mitwirkenden bereits sind, und sie werden hier angezeigt.

Ein Release pro Tag

Die Liste wird nach Tag dedupliziert: Wenn ein Tag mehr als einmal bereitgestellt wurde, beispielsweise weil der erste Build fehlgeschlagen ist und du es erneut versucht hast, wird nur die neueste Bereitstellung für dieses Tag angezeigt.

Der Zähler oben zeigt die Gesamtzahl, und die Liste umfasst ein großzügiges Fenster mit kürzlich getaggten Bereitstellungen statt der gesamten Historie des Projekts.

Releases richtig nutzen

Tag beim Merge, nicht beim Branch. Tagge den Commit, der tatsächlich auf deinem Production-Branch ist. Einen Commit aus einem Feature-Branch zu taggen, der nicht zusammengeführt wurde, erzeugt einen Release, der nichts auf main entspricht.

Verwende semantische Versionen. Sie sortieren korrekt, werden als versionsförmig erkannt, und jeder weiß bereits, wie man sie liest.

Verschiebe niemals einen Tag. Ein bestehenden Tag auf einen neuen Commit umzuleiten bedeutet, dass der Release in dieser Liste und der Tag in deinem Repository sich jetzt nicht einig sind, was eingegeben wurde. Schneiden Sie stattdessen eine neue Patch-Version aus.

Ein Tag-Push deployed direkt in die Production, wenn er deinem Pattern entspricht. Das umgeht nichts anderes: Deploy Locks, Genehmigungsanforderungen und Freeze Windows gelten weiterhin wie konfiguriert. Aber es bedeutet, dass ein versehentlich gepushter Tag ein Production Deploy ist, kein Entwurf. Siehe Deploying Your Project für die verfügbaren Gates.

Ein Release zurückrollen

Releases sind Deployments, also das Zurückrollen eines ist der normale Rollback-Workflow: Öffne das Deployment und stelle das vorherige erfolgreiche wieder her. Siehe Rolling Back a Deployment.

Danach schneide einen neuen Tag für den Fix, statt den schlechten zu löschen. Der fehlgeschlagene Release, der in der Historie sichtbar bleibt, ist nützliche Information, nicht Unordnung.

Fehlerbehebung

Ein Tag wurde gepusht, aber kein Release erschien. Überprüfe das Pattern in Settings, überprüfe dann, dass der Tag tatsächlich die Remote erreicht hat. git push origin v1.4.0 pusht einen Tag; git push allein pusht keinen.

Das Release zeigt Failed. Der Build ist fehlgeschlagen, genauso wie bei einem Branch-Push. Öffne das Deployment und lies das Log: Reading Build Logs.

Der View on-Link fehlt. Das Projekt hat kein verbundenes Repository, daher gibt es nichts zu verlinken. Verbinde eines: siehe Connecting a GitHub Repository.

Ein manuell getaggtes Deployment ist nicht aufgelistet. Das Tag ist nicht versionsförmig. Benenne es in etwas wie v1.4.0 um.

Release Notes sind leer. Notizen werden aus einem veröffentlichten Release in deinem Repository gezogen. Ein einfacher Tag ohne Release-Objekt hat keine Notizen zum Ziehen.

Nächste Schritte

Deploying Your Project für den vollständigen Deploy-Zyklus und seine Gates.
Rolling Back a Deployment wenn ein Release schiefgeht.
Orbit Timeline Annotations um zu dokumentieren, was ein Release geändert hat.