Orbit Releases

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.

De tab Releases zet je git tags om in een versiegeschiedenis die je kunt lezen: elke getagde deployment, op volgorde, met zijn commit, zijn auteur, zijn status en een directe link naar de tag in je repository.

Waar Releases zich bevindt

Open Orbit, klik op het project en kies Releases onder de Deployments groep in de projecttab strip. De pagina heet Releases en beschrijft zichzelf als tag-gebaseerde deployments: een release wordt gemaakt wanneer een git tag overeenkomt met je tag pattern.

De naburige Deployments tab geeft een lijst van elke build, getagd of niet. Releases is de gefilterde weergave: alleen degene die je als versie hebt gemarkeerd.

Het Tag Pattern instellen

Releases beginnen met een pattern. Open Settings, zoek de Git tag deploys kaart en voer een glob in zoals v* of release-*. Als je het leeg laat, worden tag deploys volledig uitgeschakeld, daarom leest de placeholder van het veld v* (disabled).

Met een pattern ingesteld, voert het pushen van een overeenkomende tag een deployment naar production uit en registreert het resultaat als een release. Zonder pattern toont de Releases tab een lege staat die je vraagt om een tag te pushen en een pattern in Settings in te stellen.

Een tag pattern geeft je een tweede, expliciete weg naar production naast pushes naar de production branch. Teams die willen dat deployments een bewuste actie zijn in plaats van een bijwerking van merging, schakelen branch auto-deploy uit en sturen production alleen via tags.

Een Release uitbrengen

De hele flow van jouw kant is twee git commando's:

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

Orbit ontvangt de tag, vergelijkt deze met je pattern, voert de getagde commit naar production in en registreert een release. Deze verschijnt op dit tabblad met een Building badge en gaat naar Deployed wanneer deze binnenkomt, of Failed als de build een fout had.

Gebruik geannoteerde tags in plaats van lichtgewicht tags. Een geannoteerde tag draagt een bericht, een auteur en een datum bij zich, die allemaal op de release terechtkomen.

Een bestaande deployment taggen

Je hoeft geen git tag te pushen om een release te krijgen. Elke deployment kan vanaf zijn detailpagina worden getagd, en een tag die eruitziet als een versienummer wordt hier opgehaald.

Een versie-vormige tag is er een zoals 1.4, 1.4.0, v1.4.0 of v2.0.0-rc1. Alles ander blijft een gewone deployment tag en creëert geen release entry.

Dit is het ontsnappingsluik voor het geval dat een release is uitgegaan voordat je het pattern instelde, of wanneer een hotfix handmatig werd gedeployed en je wilt het toch in de versiegeschiedenis hebben.

Een Release lezen

Elke release rij toont:

De tag, als titel van de release.
De commit en zijn bericht.
De auteur, getoond als by name.
De omgeving waarin het naartoe ging, kleurgecodeerd per type.
Een status badge: Deployed, Building of Failed.
Een View on link naar de tag in je repository.
Een link door naar de onderliggende deployment.

De View on link wijst naar de juiste plaats per provider: de releases pagina op GitHub, de tag pagina op GitLab, of de bron op die tag op Bitbucket.

Release Notes

Als je een release in je repository voor een tag publiceert, worden de notities overgenomen en aan de deployment gekoppeld, zodat het Releases tabblad dezelfde tekst draagt die je in je repository hebt geschreven in plaats van dat je twee kopieën moet bijhouden.

Dit maakt de repository de enige plaats om release notes te schrijven. Schrijf ze eenmaal, waar je medewerkers al zijn, en ze verschijnen hier.

Eén Release per Tag

De lijst is gededupliceerd per tag: als een tag meer dan eenmaal is gedeployed, bijvoorbeeld omdat de eerste build mislukte en je het opnieuw probeerde, wordt alleen de meest recente deployment voor die tag weergegeven.

De teller bovenaan geeft het totaal, en de lijst dekt een ruim venster van recente getagde deployments in plaats van de hele geschiedenis van het project.

Releases goed gebruiken

Tag bij merge, niet op de branch. Tag de commit die werkelijk op je production branch staat. Het taggen van een feature branch commit die nog niet is gemerged, produceert een release die niet overeenkomt met iets op main.

Gebruik semantic versions. Ze sorteren correct, worden herkend als versie-vormig en iedereen weet al hoe ze te lezen.

Verplaats een tag nooit. Een bestaande tag naar een nieuwe commit wijzen betekent dat de release in deze lijst en de tag in je repository het nu oneens zijn over wat er is gedeployed. Knip in plaats daarvan een nieuwe patch versie.

Een tag push voert rechtstreeks naar production uit als deze overeenkomt met je pattern. Dat omzeilt niets anders: deploy locks, approval requirements en freeze windows zijn nog steeds van toepassing zoals geconfigureerd. Maar het betekent wel dat een per ongeluk geduwd tag een production deploy is, geen concept. Zie Je Project deployen voor de beschikbare gates.

Een Release terugdraaien

Releases zijn deployments, dus het terugdraaien van een ervan is de gewone rollback flow: open de deployment en herstel de vorige succesvolle. Zie Een Deployment terugdraaien.

Daarna knip je een nieuwe tag voor de fix in plaats van de slechte tag te verwijderen. De mislukte release die zichtbaar blijft in de geschiedenis is nuttige informatie, geen rommel.

Probleemoplossing

Een tag werd gepusht maar er verscheen geen release. Controleer het pattern in Settings en controleer vervolgens of de tag echt op de remote terecht is gekomen. git push origin v1.4.0 pusht een tag; git push alleen pusht er geen.

De release toont Failed. De build is mislukt, precies zoals het zou gebeuren voor een branch push. Open de deployment en lees het log: Build Logs lezen.

De View on link ontbreekt. Het project heeft geen verbonden repository, dus er is geen plaats waar je naar kunt linken. Verbind er een: zie Een GitHub Repository verbinden.

Een handmatig getagde deployment wordt niet vermeld. De tag ziet er niet versie-vormig uit. Hernoem het naar iets als v1.4.0.

Release notes zijn leeg. Notities worden overgenomen van een gepubliceerde release in je repository. Een kale tag zonder release object heeft geen notities om over te nemen.

Waar vervolgens naartoe

Je Project deployen voor de volledige deploy cyclus en zijn gates.
Een Deployment terugdraaien wanneer een release fout gaat.
Orbit Timeline Annotations om op te nemen wat een release veranderde.