Orbit
Pipeline di Distribuzione Orbit
The Pipeline tab is a single page that answers "what happens when we push". It shows every way a deploy can be triggered, every gate that can stop one, the state of each environment, and which build…
Orbit Deployment Pipeline
La scheda Pipeline è una singola pagina che risponde a "cosa succede quando facciamo un push". Mostra ogni modo in cui un deployment può essere attivato, ogni gate che può bloccarne uno, lo stato di ogni ambiente e quali funzioni di build sono attive, tutto letto dalla configurazione reale del tuo progetto.
Dove si trova la Pipeline
Apri Orbit, fai clic sul progetto e scegli Pipeline sotto il gruppo Deployments nella striscia di schede del progetto. La pagina è etichettata Deployment pipeline.
È una dashboard di sola lettura. Nulla viene configurato qui: ogni sezione rimanda a dove l'impostazione si trova realmente. Questo è il suo valore: una sola schermata per capire il progetto, invece di leggere otto carte di impostazioni.
Avvisi in alto
Due banner compaiono quando applicabili:
- Deploy lock active, con un link Manage. I deploy attivati da push vengono saltati.
- N deployments awaiting approval, con un link Review. Qualcuno deve approvare o rifiutare i deployment.
Se uno di questi viene visualizzato e ti stai chiedendo perché un push non è stato deployato, hai la risposta senza leggere oltre.
Statistiche di Build
Un pannello compatto mostra, nei build recenti: tasso di successo, tempo medio di build e quanti hanno avuto successo. È un controllo di salute piuttosto che un'analisi. Per il quadro completo, vedi Orbit Project Analytics e Orbit Build Insights.
Fonti di Attivazione
Questa sezione elenca ogni percorso verso un deployment per questo progetto:
| Fonte | Cosa mostra |
|---|---|
| Git push | Il repository connesso, oppure No repo connected |
| Branch previews | Se le anteprime vengono create automaticamente su qualsiasi ramo |
| Git tag | Il pattern del tag, se configurato |
| Manual deploy | Sempre disponibile |
Leggi questa sezione ogni volta che sei sorpreso da un deployment. Se un build è apparso e nessuno ha fatto un push, una di queste è la spiegazione: un tag, un deploy hook, o qualcuno che preme un pulsante.
Gate e Sicurezza
La sezione più grande è l'elenco dei gate, ciascuno che mostra il suo stato attuale con un link Configure verso la carta delle impostazioni pertinente.
| Gate | Cosa fa |
|---|---|
| Approval gate | I deployment in produzione richiedono approvazione esplicita |
| Staging prerequisite | La produzione attende staging nello stesso commit |
| CI checks | Controlli richiesti che devono passare, oppure No checks required |
| Freeze window | Weekend bloccati, ore personalizzate, oppure nessuna programmazione di freeze |
| Deploy lock | Attivo, oppure nessun lock |
| Health check | Il percorso controllato dopo il deployment, oppure Disabled |
| Auto-rollback | Revoca al fallimento del controllo di salute |
| Skew protection | La finestra di conservazione per gli asset vecchi |
| Auto retry | Quante volte vengono ritentati i fallimenti dell'infrastruttura |
La maggior parte di questi gate si applica solo ai deployment attivati da push. I deployment manuali dal pannello e i deploy hook passano direttamente. L'eccezione si comporta diversamente e il dettaglio di ogni gate è trattato in Deploying Your Project. Leggi quello prima di affidarti a un gate come controllo.
Lettura dei Gate come Checklist
Per un progetto importante, una linea di base ragionevole è:
- Health check: configurato, che punta a un percorso che esercita l'app piuttosto che una shell in cache.
- Auto-rollback: attivo. Senza un controllo di salute non ha nulla su cui agire, quindi i due vanno insieme.
- Auto retry: uno o due. Rimette in coda i build che hanno fallito su errori infrastrutturali come un problema di rete, e non ritenta errori di codice, quindi non ti costa nulla se non tempo risparmiato.
- Approval gate: attivo per qualsiasi cosa dove un deployment errato è costoso, spento dove ti rallenta più di quanto ti protegga.
Se la pagina mostra Health check Disabled e Auto-rollback attivo, quella combinazione non fa nulla. È una delle errate configurazioni più facili da portare avanti per mesi senza accorgersene, ed è su questa pagina che la individualizzi.
Flusso Ambiente
La sezione Environment flow disegna ogni ambiente come una carta con il suo stato attuale: LIVE, BUILDING o PAUSED, il ramo che traccia, e il numero di ritentativo se il deployment attuale è un ritentativo.
I badge su ogni carta mostrano cosa è abilitato per quell'ambiente:
- Smoke tests, richieste GET eseguite su percorsi scelti dopo ogni deployment riuscito.
- Auto-promote, promozione di staging a produzione dopo un numero di ore sane.
- Canary, la percentuale di traffico su un deployment canary.
- Inherits prod vars, dove staging unisce le variabili di ambiente di produzione con priorità inferiore.
- Scheduled rebuild, dove la produzione si ricostruisce su un intervallo.
Ogni carta rimanda ai deployment di quell'ambiente. Se un ambiente dice No deployments yet, esiste in configurazione ma nulla è stato spedito ad esso.
Funzioni Attive
L'ultima sezione riassume le impostazioni a livello di build:
| Funzione | Valori |
|---|---|
| Server mode | SSR abilitato o solo statico |
| Auto-create on push | Se i push di ramo creano ambienti |
| Health checks | Attivo o spento |
| Build retry | Un massimo, o spento |
| Deploy groups | Raggruppato con altri progetti, oppure autonomo |
| Build timeout | Il limite per build |
| Preview expiry | Giorni prima che le anteprime siano messe in pausa, o mai |
Server mode è quello che blocca le persone. Un framework che esegue il rendering sul server ha bisogno che sia attivo: un'esportazione statica no. Se il tuo progetto si costruisce bene e poi serve una pagina bianca o un 404 su ogni percorso tranne la home page, controlla questo per primo. Vedi Frameworks Orbit Supports.
Preview expiry è quello della manutenzione. Se impostato su mai, gli ambienti di anteprima si accumulano indefinitamente.
Utilizzo della Pagina Pipeline
Quando onboardi qualcuno. Invialo qui per primo. È un briefing più veloce e accurato rispetto a qualsiasi documento, perché è generato dalla configurazione live.
Quando un deployment non è avvenuto. Procedi dall'alto verso il basso: banner, quindi fonti di attivazione, quindi gate. Uno dei tre lo spiegherà.
Prima di una release rischiosa. Controlla che la sezione gate legga il modo in cui pensi. È la differenza tra credere di avere auto-rollback e averlo.
Durante un incidente. Il flusso ambiente ti dice cosa è live dove, e se qualcosa è in fase di build.
Risoluzione dei Problemi
La pagina mostra No repo connected. Il progetto non ha repository. Collegane uno: vedi Connecting a GitHub Repository.
Un gate è attivo ma i deployment continuano a passare. È solo attivato da push. Un deploy hook o un deployment dal pannello manuale non è interessato.
Un ambiente mostra PAUSED. Gli ambienti di anteprima si mettono in pausa automaticamente una volta passata la loro scadenza. Fai un redeploy per portarne uno indietro.
Auto-promote è mostrato ma nulla viene promosso. Richiede il numero configurato di ore sane con gli smoke tests che passano, ed è valutato periodicamente piuttosto che istantaneamente.
Dove Andare Dopo
- Deploying Your Project per cosa ogni gate blocca effettivamente.
- Orbit Project Settings per modificare qualsiasi cosa.
- Rolling Back a Deployment quando un gate non ti ha salvato.