Orbit
Ripristino di una distribuzione
If a deployment breaks production, you can put an earlier build back in front of traffic in seconds without rebuilding anything. This guide covers how rollback works, how to pick the right…
Se una distribuzione interrompe la produzione, puoi rimettere una build precedente davanti al traffico in secondi senza ricostruire nulla. Questa guida copre come funziona il rollback, come scegliere la distribuzione giusta, i rollback automatici che Orbit può eseguire per te, e cosa fare dopo aver eseguito il rollback.
Come funziona il rollback
Orbit mantiene l'artefatto confezionato di ogni build riuscita. Un rollback non riesegue il tuo install o il tuo comando build: promuove un artefatto che esiste già ed è stato già servito, quindi si completa in secondi e non può fallire per nessuno dei motivi per cui una build può fallire.
Questo è il motivo principale per cui ricorrere a questo per primo. Il rollback è più veloce e molto più prevedibile rispetto al tentativo di risolvere il problema mentre il tuo sito è rotto.
Eseguire il rollback a una distribuzione precedente
- Apri il tuo progetto in Orbit.
- Apri la scheda Deployments.
- Trova l'ultima distribuzione che sai fosse buona.
- Fai clic su Roll back su quella riga e conferma.
La conferma dice esattamente cosa accadrà: il traffico verrà servito dalla build più vecchia immediatamente, e la distribuzione corrente sarà sostituita.
Puoi anche eseguire il rollback dalla pagina dei dettagli della distribuzione stessa, dove il pulsante legge Rollback to con l'hash del commit abbreviato.
La distribuzione ripristinata riceve il badge CURRENT. La distribuzione da cui hai eseguito il rollback rimane nella cronologia con lo stato Rolled back.
Il rollback non è distruttivo e non ha bisogno di essere annullato. Niente viene eliminato, nessuna cronologia viene riscritta, e il tuo repository rimane intatto. Il tuo prossimo push riuscito al ramo di produzione semplicemente diventa la nuova versione live nel modo normale.
Identificare la distribuzione giusta
Ogni riga nella scheda Deployments mostra il messaggio di commit e l'hash abbreviato, il ramo, lo stato, quando è stata distribuita, e chi l'ha inviata. Quella live porta il badge CURRENT.
Di solito vuoi la distribuzione immediatamente precedente a quella che ha causato il problema. Due cose ti aiutano a essere sicuro:
- Compare. Apri la distribuzione sospetta e fai clic su Compare per confrontarla con la precedente: tempo di build, dimensione dell'artefatto, stato della cache, framework, e la differenza di artefatto a livello di file.
- Deployment notes. Qualsiasi distribuzione può portare una nota di massimo 500 caratteri. Aggiungere "hotfix for payment bug" o "feature flag X on" al momento non costa nulla e rende la cronologia leggibile mesi dopo, che è esattamente quando ne hai bisogno.
Il rollback a un artefatto non esegue il rollback delle tue variabili di ambiente, regole di reindirizzamento o header di risposta. Questi sono letti al momento della richiesta o della build, non incorporati nell'artefatto. Se l'incidente è stato causato da una modifica della configurazione piuttosto che da una modifica del codice, il rollback del codice non lo risolverà. La pagina dei dettagli della distribuzione confronta le variabili iniettate al momento della build rispetto alla configurazione attuale, che è il modo più veloce per distinguere le due cose.
Rollback automatico
Orbit può farlo per te prima ancora che tu l'abbia notato. Tutte e tre le impostazioni sono in Settings.
Auto-Rollback on Failure
In Runtime, attiva Auto-rollback on failure. Se una distribuzione di produzione fallisce, l'ultima distribuzione sana viene ripristinata automaticamente e i visitatori non vedono alcun downtime. Staging ha un interruttore equivalente suo.
Health Check
In Health check, imposta un Health check path, ad esempio / o /api/health. Dopo ogni distribuzione di produzione, Orbit recupera quel percorso. Se non restituisce una risposta 2xx entro 15 secondi, la distribuzione sana precedente viene ripristinata.
Smoke Tests
In Smoke tests, elenca fino a 10 percorsi separati da virgole, ad esempio /,/blog,/api/health. Dopo ogni distribuzione riuscita, Orbit invia un GET a ciascuno e registra pass o fail. Se uno fallisce e il rollback automatico è abilitato, la distribuzione precedente viene ripristinata. Il risultato appare sulla pagina di distribuzione come Smoke tests passed o un conteggio dei guasti, e dice Triggered rollback quando ne ha causato uno.
Un health check su una route che effettivamente esercita il tuo database vale molto più di uno sulla home page. Una distribuzione rotta che serve ancora una home page in cache passerà un controllo / e fallirà uno vero.
Rollback rispetto a Deploy Lock
Se non sei pronto a eseguire il rollback ma vuoi impedire che qualcosa di nuovo vada live mentre indaghi, blocca invece le distribuzioni:
- Apri il progetto.
- Fai clic su Lock deploys.
- Aggiungi un motivo, ad esempio "investigating production issue".
Le distribuzioni attivate da push vengono quindi silenziosamente saltate, e un banner legge Production deploys are locked con il tuo motivo. Le distribuzioni manuali funzionano ancora, il che è intenzionale: il blocco impedisce distribuzioni accidentali, non la correzione che stai spedendo. Fai clic su Unlock deploys per rimuoverlo.
Un blocco e un rollback funzionano bene insieme. Esegui il rollback prima per ripristinare il servizio, poi blocca in modo che il merge ordinario di nessuno non lo annulli mentre stai diagnosticando.
Promuovere Staging a Produzione
Se gestisci un ambiente di staging, puoi mettere una build di staging testata in produzione senza spingere nulla.
- Apri la panoramica del progetto e trova la sezione Staging.
- Se staging è avanti rispetto alla produzione, appare Promote to production.
- Fai clic su di esso e conferma.
Leggi attentamente la conferma, perché ci sono due diversi comportamenti di promozione in Orbit e non sono intercambiabili. Promuovere dalla panoramica del progetto attiva una fresh production build at the same commit, utilizzando le variabili di ambiente di produzione e i comandi di build di produzione. L'artefatto di staging non viene riutilizzato. Promuovere una distribuzione di staging specifica dalla sua pagina di dettagli dichiara chiaramente che la build di staging va live immediatamente senza una ricostruzione. Se le tue variabili di ambiente di staging e di produzione differiscono, il primo percorso produrrà un artefatto diverso da quello che hai testato.
Orbit può anche promuovere per te. Auto-promote staging in Settings promuove staging a produzione dopo un numero di ore di staging sano con smoke tests che passano, controllato ogni 15 minuti.
Dopo un rollback
Correggi il problema sottostante nel tuo repository e invia un nuovo commit. Questo attiva una build normale che diventa la nuova versione live. Se hai bloccato le distribuzioni, sblocca prima, o il push verrà saltato.
La scheda Activity del progetto registra il rollback insieme a tutto il resto che è accaduto, quindi c'è un audit trail di chi ha fatto rollback di cosa e quando.
Cosa limita quanto indietro puoi andare
Il rollback ha bisogno che l'artefatto esista ancora. Due impostazioni controllano questo:
- La finestra della cronologia di distribuzione del tuo piano: 7 giorni su Launch, 30 su Liftoff, 90 su Apex.
- L'impostazione Artifact retention del progetto, che mantiene un numero di artefatti riusciti per ambiente, da 10 a 500, predefinito a 50.
L'artefatto della distribuzione attualmente live viene sempre mantenuto indipendentemente da entrambi.
Se distribuisci molte volte al giorno, il conteggio degli artefatti è il limite che colpirai per primo, non il conteggio dei giorni. Cinquanta distribuzioni possono essere una singola settimana. Aumenta Artifact retention piuttosto che scoprire il limite durante un incidente.