Impostazioni del Progetto Orbit

Ogni controllo per un progetto Orbit si trova nella scheda Impostazioni, raggruppato in modo da facilitare la ricerca: informazioni generali, build e deploy, sicurezza, notifiche, integrazioni, limiti di utilizzo, automazione del deploy, networking, osservabilità, condivisione e una zona pericolosa in fondo.

Dove si trovano le Impostazioni

Apri Orbit, fai clic sul progetto e scegli Impostazioni nella barra di schede del progetto. La pagina descrive sé stessa come configurazione del nome del progetto, comandi di build e integrazione Git, il che non le rende completamente giustizia.

Questa guida è una mappa. Quando un argomento ha un articolo proprio, è collegato anziché ripetuto.

Generale

Informazioni progetto mostra lo slug URL, la data di creazione, il repository collegato e l'URL di produzione, e ti consente di modificare il Nome e la Descrizione del progetto.

Git contiene il Production branch. I push su quel branch attivano i deploy di produzione.

Status badge ti fornisce un SVG di stato del deploy live con pulsanti di copia per l'URL, markdown e HTML, pronto per essere incollato nel tuo README. Vedi Visualizzazione del README del Progetto in Orbit.

Public status page rimanda alla configurazione della pagina di stato. Vedi Orbit Status Page.

Build e Deploy

Build settings sono i cinque campi che Orbit rileva automaticamente e che puoi sovrascrivere: comando di installazione, comando di build, directory di output, directory root e versione di Node.js. Lascia un campo vuoto per mantenere il valore rilevato. Tutti i dettagli sono in Configurazione del Comando di Build e della Directory di Output.

Runtime presenta quattro switch che vale la pena comprendere:

• Server mode mantiene la macchina di build attiva eseguendo il tuo comando start dopo ogni deploy. Richiesto per tutto ciò che esegue il rendering sul server piuttosto che esportare file statici.
• Branch previews creano un ambiente automaticamente per ogni push di branch che non è produzione o staging, ognuno su un proprio URL sotto branch-*.kaps.run. Vedi Branch Previews.
• Auto-rollback on failure ripristina l'ultimo deploy di produzione integro se un deploy non riesce.
• Scheduled rebuild ricostruisce la produzione a intervalli, da oraria a settimanale, il che è adatto ai siti gestiti da contenuti che necessitano di un aggiornamento senza un push git.

Build auto-retry rimette in coda i build che non hanno avuto esito positivo a causa di errori infrastrutturali come un problema di rete o un timeout, fino a tre volte. Non ritenta gli errori di codice, quindi non può mascherare un build interrotto.

Ignored paths e Branch ignore patterns fermano i build di cui non hai bisogno: modelli glob per file le cui modifiche non dovrebbero essere distribuite, e per branch come dependabot/* che non dovrebbero mai attivarne uno.

Git tag deploys imposta il modello di tag che trasforma un push di tag in un deploy di produzione. Vedi Orbit Releases.

Automazione e Protezione del Deploy

Deploy protection ha due gate: Require approval for production, che sospende i deploy di produzione attivati da push fino a quando qualcuno approva, e Require staging success before production, che blocca la produzione finché staging non ha distribuito lo stesso commit con successo.

CI required checks blocca i deploy sul tuo CI. Su GitHub elencherai i nomi dei job, che devono tutti avere successo; su GitLab qualsiasi valore non vuoto attende l'intera pipeline. Un errore di CI annulla il deploy.

Deploy freeze schedule blocca i deploy attivati da push al di fuori delle finestre approvate, sia nei fine settimana che in un intervallo orario UTC. I deploy manuali e i deploy hook non sono interessati.

Branch protection aggiunge regole con pattern glob che bloccano i deploy su branch corrispondenti fino a quando i controlli esterni richiesti non sono soddisfatti e, facoltativamente, un essere umano approva.

Auto-promote staging promuove lo staging alla produzione automaticamente una volta che è stato eseguito per un numero configurato di ore senza errori di salute e con i test di fumo superati.

Tutti questi sono riassunti in un'unica vista nella scheda Orbit Deployment Pipeline.

Health e Quality Gates

Health check recupera un percorso a tua scelta dopo ogni deploy di produzione. Una risposta non-2xx entro 15 secondi ripristina il precedente deploy di produzione integro.

Smoke tests eseguono richieste GET contro fino a dieci percorsi separati da virgola dopo ogni deploy riuscito e registrano successo o fallimento. Combinato con auto-rollback, uno smoke test fallito esegue il rollback del deploy.

Performance budgets avvisano o interrompono i build che superano una soglia: dimensione totale dell'artefatto in MB, dimensione del singolo file in kB corrispondente a un glob, o tempo di build in secondi. Ogni budget è impostato su avviso o per interrompere il build.

Staging

Staging ha il suo set di schede: il staging branch, access protection con una password, un IP allowlist che accetta indirizzi IPv4 e intervalli CIDR uno per riga, auto-rollback on failure, se staging eredita le variabili d'ambiente di produzione con priorità inferiore, e build overrides per install, build, output e directory root.

Password e IP allowlist sono i due da impostare su qualsiasi ambiente di staging non destinato a essere pubblico. Lascia entrambi vuoti e l'URL di staging è raggiungibile da chiunque lo abbia.

Networking

Custom domains aggiunge e verifica i domini per l'ambiente di produzione, incluso il provisioning dei certificati. Vedi Aggiunta di un Dominio Personalizzato a Orbit.

Redirects and rewrites sono regole basate su percorsi applicate prima della distribuzione, testate in ordine con la prima corrispondenza che vince. Un redirect invia il browser a un nuovo URL come 301 o 302; una rewrite distribuisce un percorso diverso silenziosamente senza cambio di URL. I modelli supportano corrispondenze esatte, wildcard, parametri denominati e splat. Vedi Redirects and Rewrites in Orbit.

Response headers applica intestazioni HTTP personalizzate ai percorsi corrispondenti, con preset per HSTS, CSP, no-embed, no-sniff, referrer policy e CORS. Tutte le regole corrispondenti vengono applicate e le voci successive sovrascrivono quelle precedenti per la stessa chiave.

Skew protection mantiene gli artefatti di build precedenti in storage per una finestra di conservazione dopo che un nuovo deployment va live, in modo che un visitatore che ha caricato la versione precedente possa ancora recuperare i suoi asset invece di ricevere un 404.

The config store contiene impostazioni chiave/valore che il tuo deployment legge in runtime, per flag di funzionalità e impostazioni che cambiano senza un redeploy. È gestito in Storage, non qui, ed è gratuito: non c'è nessuna commissione di lettura e nessuna commissione di scrittura. I valori sono memorizzati in testo semplice, quindi non mettere mai un segreto in uno. Fino a 100 voci per progetto, chiavi fino a 200 caratteri e valori fino a 4096. Uno snapshot notturno di ogni voce viene eseguito e trenta notti vengono conservate su ogni piano, quindi una voce che elimini può essere ripristinata: vedi Snapshots and restore.

Utilizzo e Limiti

Build usage mostra i build che questo progetto ha eseguito.

Spending cap imposta la spesa mensile massima dei costi aggiuntivi, coprendo gli eccedenti di build-minute e larghezza di banda oltre l'allocazione del tuo piano. Il minimo è US$6.32 e il massimo US$6,315.79. Gli avvisi si attivano al 50% e all'80%, e al 100% la distribuzione si sospende finché non aumenti il cap. Vedi Orbit Spending Cap.

Build spending cap è il limite separato e più grezzo: un tetto mensile sul totale dei build minutes, dopodiché i nuovi build smettono di essere accodati fino al mese prossimo o fino a quando non aumenti il cap.

Artifact retention imposta quanti artefatti di build riusciti mantenere per ambiente. I più vecchi vengono eliminati quotidianamente e il deploy attualmente live viene sempre mantenuto indipendentemente dal limite.

Preview expiry mette in pausa gli ambienti di preview dopo 7, 14, 30 o 60 giorni, o mai. I preview in pausa hanno il loro storage recuperato entro 24 ore.

Artifact size alert ti invia un'email quando un artefatto di build supera una dimensione che hai impostato.

Notifiche, Integrazioni e Osservabilità

Deploy email notifications ha tre impostazioni: tutti i deploy, solo i fallimenti, o disattivato. Un notification webhook URL può essere impostato insieme ad esso, postando ad ogni successo o fallimento.

Notification channels è la versione più ricca, con selezione per evento, cronologia di consegna e un pulsante di test. Il controllo completo del webhook è su una sua scheda: vedi Orbit Webhooks.

Deploy hooks crea URL segreti che attivano un deploy quando qualcosa li POSTa. Vedi Triggering Deployments Via Deploy Hooks.

Log drains spedisce i build log alla tua piattaforma di osservabilità dopo ogni deployment, con supporto integrato per Datadog, Logtail, Axiom e New Relic, o un webhook personalizzato, facoltativamente filtrato a un ambiente.

Web Analytics ti fornisce lo snippet di raccolta Core Web Vitals. Vedi Orbit Web Vitals.

Cron triggers pianifica richieste HTTP a un ambiente scelto, fino a dieci per progetto. La versione più grande, solo per la produzione, è su una sua scheda: vedi Orbit Cron Jobs.

Condivisione e Team

Team gestisce i collaboratori con tre ruoli: admin, developer e viewer.

Share links generano link temporanei senza password in modo che un revisore esterno possa visualizzare un ambiente senza password o account. Ogni link può scadere in 1 ora, 24 ore o 7 giorni, o mai, e mostra il suo conteggio di visite. Revoca uno in qualsiasi momento.

Deployment group unisce questo progetto a un gruppo in modo che i progetti correlati si distribuiscano insieme, facoltativamente filtrati per branch.

Clone environment e Clone project duplicano la configurazione. La clonazione di un progetto copia build settings, configurazione dell'ambiente e variabili d'ambiente non segrete; i segreti non vengono copiati.

Danger Zone

Clear build cache elimina le dipendenze memorizzate nella cache per ogni ambiente, in modo che il prossimo deployment esegua un'installazione completa da zero. Non può essere annullato, anche se la cache si ricostruisce da sola al prossimo build.

Transfer project sposta il progetto su un altro account Kapsule. Vedi Trasferimento di un Progetto Orbit.

Archive project smette di servire il traffico immediatamente. È ripristinabile entro 30 giorni dall'elenco Orbit, dopodiché viene eliminato definitivamente.

Dove andare dopo

• Orbit Deployment Pipeline per vedere l'effetto di ogni impostazione in un'unica visualizzazione.
• Shared Environment Variable Groups per valori utilizzati in più progetti.
• Orbit Plan Limits per ciò che il tuo piano consente.