Orbit
Rilasci di Orbit
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.
La scheda Releases trasforma i tuoi git tag in una cronologia delle versioni che puoi leggere: ogni deployment taggato, in ordine, con il suo commit, il suo autore, il suo stato e un collegamento diretto al tag nel tuo repository.
Dove si trovano i Releases
Apri Orbit, fai clic sul progetto e scegli Releases nel gruppo Deployments nella barra delle schede del progetto. La pagina è intitolata Releases e si descrive come deployment basati su tag: un release viene creato quando un git tag corrisponde al tuo modello di tag.
La scheda Deployments adiacente elenca ogni build, taggata o meno. Releases è la visualizzazione filtrata: solo quelli che hai contrassegnato come versione.
Impostazione del modello di tag
I Releases iniziano con un modello. Apri Settings, trova la scheda Git tag deploys e inserisci un glob come v* o release-*. Se la lasci vuota, disabiliti completamente i tag deploy, motivo per cui il placeholder del campo recita v* (disabled).
Con un modello impostato, il push di un tag corrispondente esegue il deploy in produzione e registra il risultato come release. Senza uno, la scheda Releases mostra uno stato vuoto che ti invita a fare il push di un tag e impostare un modello in Settings.
Un modello di tag ti offre un secondo percorso esplicito verso la produzione insieme ai push verso il ramo di produzione. I team che vogliono che i deploy siano un atto deliberato piuttosto che un effetto collaterale del merge spesso disattivano l'auto-deploy del ramo e gestiscono la produzione solo dai tag.
Creazione di un Release
L'intero flusso dal tuo lato è costituito da due comandi git:
git tag -a v1.4.0 -m "Checkout flow rebuild"
git push origin v1.4.0
Orbit riceve il tag, lo abbina al tuo modello, esegue il deploy del commit taggato in produzione e registra un release. Appare su questa scheda con un badge Building e passa a Deployed quando arriva, oppure a Failed se la build ha generato un errore.
Usa tag annotati invece di quelli leggeri. Un tag annotato porta un messaggio, un autore e una data, il tutto finisce nel release.
Tagging di un Deployment esistente
Non devi eseguire il push di un git tag per ottenere un release. Qualsiasi deployment può essere taggato dalla sua pagina di dettaglio e un tag che ha l'aspetto di un numero di versione viene rilevato qui.
Un tag con forma di versione è uno come 1.4, 1.4.0, v1.4.0 o v2.0.0-rc1. Tutto il resto rimane come un semplice tag di deployment e non crea una voce di release.
Questo è lo scappatoie per il caso in cui un release sia uscito prima di aver impostato il modello, o in cui un hotfix sia stato eseguito manualmente e tu voglia includerlo comunque nella cronologia delle versioni.
Lettura di un Release
Ogni riga di release mostra:
- Il tag, come titolo del release.
- Il commit e il suo messaggio.
- L'autore, mostrato come by name.
- L'ambiente a cui è andato, codificato a colori per tipo.
- Un badge di stato: Deployed, Building o Failed.
- Un link View on verso il tag nel tuo repository.
- Un collegamento al deployment sottostante.
Il link View on punta al posto giusto per provider: la pagina dei release su GitHub, la pagina del tag su GitLab, o il sorgente a quel tag su Bitbucket.
Note di Release
Se pubblichi un release nel tuo repository per un tag, le note vengono trasferite e allegate al deployment, in modo che la scheda Releases contenga lo stesso testo che hai scritto nel tuo repository piuttosto che costringerti a mantenere due copie.
Questo rende il repository l'unico posto dove scrivere le note di release. Scrivile una volta, dove i tuoi contributori si trovano già, e appariranno qui.
Un Release Per Tag
L'elenco è deduplicato per tag: se un tag è stato deployato più di una volta, ad esempio perché la prima build non è riuscita e hai riprovato, viene mostrato solo il deployment più recente per quel tag.
Il contatore in alto fornisce il totale e l'elenco copre una finestra generosa di deployment taggati recenti piuttosto che l'intera cronologia del progetto.
Utilizzo corretto dei Releases
Tagga al merge, non sul ramo. Tagga il commit che si trova effettivamente sul tuo ramo di produzione. Taggare un commit di un ramo feature che non è stato sottoposto a merge produce un release che non corrisponde a nulla su main.
Usa versioni semantiche. Si ordinano correttamente, sono riconosciute come versioni, e tutti sanno già come leggerle.
Non spostare mai un tag. Reindirizzare un tag esistente a un nuovo commit significa che il release in questo elenco e il tag nel tuo repository ora non sono d'accordo su ciò che è stato distribuito. Crea invece una nuova versione patch.
Un push di tag esegue il deploy direttamente in produzione se corrisponde al tuo modello. Ciò non aggira nient'altro: i blocchi di deploy, i requisiti di approvazione e le finestre di congelamento si applicano ancora come configurato. Ma significa che un tag inviato per errore è un deploy in produzione, non una bozza. Vedi Deploying Your Project per i gate disponibili.
Rollback di un Release
I Releases sono deployment, quindi eseguire il rollback di uno è il flusso di rollback ordinario: apri il deployment e ripristina quello precedente di successo. Vedi Rolling Back a Deployment.
Successivamente, crea un nuovo tag per la fix piuttosto che eliminare quello difettoso. Il release non riuscito che rimane visibile nella cronologia è informazione utile, non disordine.
Risoluzione dei problemi
Un tag è stato inviato ma nessun release è apparso. Controlla il modello in Settings, quindi verifica che il tag abbia effettivamente raggiunto il remote. git push origin v1.4.0 invia un tag; git push da solo non invia nulla.
Il release mostra Failed. La build non è riuscita, esattamente come accadrebbe per un push di ramo. Apri il deployment e leggi il log: Reading Build Logs.
Il link View on è mancante. Il progetto non ha un repository connesso, quindi non c'è nulla a cui collegarsi. Connettine uno: vedi Connecting a GitHub Repository.
Un deployment taggato manualmente non è elencato. Il tag non ha forma di versione. Rinominalo in qualcosa come v1.4.0.
Le note di release sono vuote. Le note vengono estratte da un release pubblicato nel tuo repository. Un tag nudo senza oggetto release non ha note da estrarre.
Dove andare dopo
- Deploying Your Project per il ciclo di deploy completo e i suoi gate.
- Rolling Back a Deployment quando un release va male.
- Orbit Timeline Annotations per registrare cosa ha cambiato un release.