Controllo del codice sorgente
Collegate l'account GitHub o GitLab in cui lavorate ed eseguite il deploy direttamente da un branch: su Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps o AWS Amplify — oppure sul nostro hosting gestito, dove il repository e i file del sito restano sincronizzati in entrambe le direzioni. Ogni connessione mostra i privilegi richiesti, viene verificata rispetto all'API del provider prima di essere memorizzata e risiede in Vault. È inoltre possibile accedere con GitHub o GitLab.
Una connessione è una credenziale fornita a un altro utente. La nostra specifica ciò di cui ha bisogno prima di essere creata, dimostra di funzionare prima di essere salvata e può essere revocata da entrambe le parti.
Prima di creare un token, vi diciamo cosa deve essere in grado di fare e perché. Nessun ambito generico solo perché era più facile da richiedere, e nessuna scoperta a posteriori di aver voluto più di quanto il lavoro richiedesse.
Interroghiamo l'API proprietaria del provider con il Suo token prima di memorizzarlo. Un token errato, scaduto o con ambito non corretto viene rifiutato direttamente nel modulo anziché essere accettato, mostrato come funzionante e fallire poi al primo vero deployment.
Non nel nostro codice, non in un file di ambiente, non in un log e non su una riga di comando. Risolto nel momento in cui viene utilizzato, dal carico di lavoro che lo utilizza.
Collegate un account personale e quello di un'organizzazione, oppure due organizzazioni. Ogni sito sceglie da quale effettuare il deployment, così il repository di un cliente e il vostro non condivideranno mai le credenziali.
Otto host edge gestiti e la nostra flotta proprietaria. La destinazione è una proprietà del sito, non della connessione, quindi lo stesso repository può pubblicare un ramo su un host Pages e un altro sito può funzionare sul nostro hardware.
Larghezza di banda illimitata, uso commerciale consentito e domini apex gestiti dallo stesso provider che di solito gestisce la Sua zona DNS. È la prima scelta a cui ricorriamo per questi motivi.
Hosting Cloudflare Pages →Pubblichi direttamente dal repository in cui risiede già il codice. Segnalato sulla riga Footprint-Free, poiché l'infrastruttura condivisa github.io costituisce essa stessa un'impronta.
Hosting GitHub Pages →GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps e AWS Amplify sono tutte destinazioni a cui è possibile indirizzare un sito, con la stessa connessione e la stessa cronologia di distribuzione.
Hosting di siti statici →Un'applicazione completa anziché un bundle compilato: WordPress, PHP, Node. Questa è la destinazione che riceve la sincronizzazione bidirezionale, così i file sulla macchina e sul branch rimangono sincronizzati.
Hosting gestito →Un sito pubblicato su un host che non è di nostra proprietà consuma comunque una quota e continua a comparire nella Sua dashboard con i suoi deployment, il suo uptime e i suoi dati SEO accanto a tutto il resto di ciò che gestisce.
Quote per siti esterni →L'editor integrato nel browser opera sugli stessi file restituiti dalla sincronizzazione bidirezionale, quindi una rapida correzione dal pannello di controllo diventa un commit sul Vostro branch anziché una modifica che nessuno riuscirà a trovare in seguito.
L'editor web →Sincronizzazione bidirezionale
Lo attivi e i file del sito stesso verranno sottoposti a commit nel Suo branch, mentre i commit su quel branch torneranno al sito. Funziona su ogni sito che ospitiamo, su ogni riga: l'unico requisito è che la macchina sottostante possa eseguire Git sui propri file, il che viene richiesto al server piuttosto che presunto dal piano.
Siete voi a scegliere quale directory sincronizzare, perché un cliente WordPress desidera che venga monitorato il proprio tema e non quarantamila file principali. Ed è disattivata finché non la attivate: abilitare una sincronizzazione è una decisione che riguarda il repository di qualcun altro, e una migrazione non deve mai prenderla al posto vostro.
Due modalità, e la differenza sta nel punto in cui viene eseguita la build. Entrambe terminano nello stesso punto: un riferimento che recuperiamo e pubblichiamo, con il commit registrato per il deployment.
GitHub o GitLab, sotto Connessioni. I privilegi vengono elencati prima di creare il token e quest'ultimo viene verificato con il provider prima di essere memorizzato.
Proprietario, repository, branch e se pubblichiamo una directory o recuperiamo ciò che ha compilato la vostra CI. Registriamo il webhook di push come parte di questo processo.
Un push al ramo designato avvia una distribuzione, oppure è possibile distribuire su richiesta dalla scheda Distribuzione del sito. Le build vengono eseguite in background.
La cronologia di deploy mostra cosa è stato pubblicato e quando. Attivi la sincronizzazione bidirezionale e le modifiche apportate qui verranno applicate come commit sul Suo branch.
In caso di problemi
Una connessione al repository che sembra integra e non riceve nulla è il classico errore silenzioso: un token con l'ambito errato, una consegna bloccata presso il provider, un hook rimosso manualmente. Risulta invisibile su qualsiasi altra schermata, pertanto la scheda del repository lo riporta direttamente: data dell'ultima consegna da parte del provider e relativo esito.
Le consegne vengono verificate tramite firma prima di procedere, utilizzando lo schema proprietario di ciascun fornitore anziché uno ritenuto valido per tutti. Una consegna che non supera la verifica viene rifiutata e registrata, non ignorata silenziosamente.
Identità
Oltre a un indirizzo e-mail e una password, può accedere al Suo account Zinn Digital® con GitHub, GitLab, Google o Microsoft. Il livello di identità esegue l'handshake; non vediamo mai la password del Suo provider e il collegamento di un account social a un account Zinn® esistente deve essere comunque confermato via e-mail.
L'accesso con GitHub e la connessione di GitHub per i deployment sono decisioni distinte e credenziali distinte. L'esecuzione di una non comporta l'altra, e la rimozione di una non rimuove l'altra.
GitHub e GitLab. Connetta l'account su cui lavora già e potremo effettuare il deployment dai suoi repository, registrare un push webhook su di essi e, se lo desidera, sincronizzare i file del Suo sito nella direzione inversa. Entrambi passano attraverso lo stesso collegamento di account connesso, quindi tutto quanto riportato di seguito si applica a ciascuno dei due.
Sì, e con Google o Microsoft. Oltre a un indirizzo e-mail e a una password, può accedere al Suo account Zinn Digital® con una qualsiasi delle quattro opzioni. Il livello di identità gestisce l'handshake e noi non vediamo mai la password del Suo provider. L'accesso con GitHub è indipendente dal collegamento di GitHub per i deployment: può eseguire l'uno, l'altro, entrambi o nessuno dei due.
Verso Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps o AWS Amplify per un sito statico o compilato, oppure sul nostro hosting gestito, dove il repository e i file del sito rimangono sincronizzati in entrambe le direzioni. Scegliete voi la destinazione del sito; la connessione al repository è la stessa in entrambi i casi.
Entrambe le opzioni. In modalità di pubblicazione prendiamo il ramo così com'è e pubblichiamo la directory indicata. In modalità CI, la pipeline del Suo provider esegue il Suo comando di build ed effettua il commit dell'output in un ramo di pubblicazione separato, che poi recuperiamo come qualsiasi altro riferimento. La seconda opzione mantiene la build all'interno della Sua CI, dove si trovano già i Suoi secret e la Sua cache.
Per impostazione predefinita, sì: registriamo un webhook nel repository e un push al branch designato avvia un deploy. È possibile disattivare questa funzione e mantenere il webhook, il che è più utile di quanto sembri: la consegna viene comunque registrata, consentendovi di monitorare l'arrivo dei vostri push prima di autorizzarci ad agire.
Le modifiche apportate sul nostro hardware diventano commit sul Suo branch, e i commit sul Suo branch ritornano al sito. È disattivato finché non lo attiva Lei, perché l'attivazione è una decisione che riguarda il repository di qualcun altro e non la prenderemo al Suo posto. Lei sceglie quale directory sincronizzare: di solito un tema o un plugin, non quarantamila file principali di WordPress.
Nulla viene sovrascritto e nulla viene inviato. La sincronizzazione si interrompe, vi informa che il branch si è spostato oltre il commit su cui ci eravamo basati e vi chiede quale lato desiderate: mantenere il repository o mantenere il sito. Un sito che non è mai stato sincronizzato e punta a un branch che presenta già dei commit costituisce a sua volta uno stato a sé stante, e preferisce chiedere piuttosto che indovinare quale sia la verità.
Le mostriamo i privilegi necessari alla connessione prima che la crei, verifichiamo il token rispetto all'API del fornitore stesso all'inserimento — in modo che un token non valido o con ambito errato non venga mai memorizzato — e solo allora lo scriviamo in Vault. Non tocca mai il nostro codice, un registro, un file di ambiente o una riga di comando. Lo revochi presso il fornitore o rimuova la connessione qui, ogni volta che lo desidera.
La scheda del repository mostra l'ultimo recapito da parte del provider e il relativo contenuto. "Mai recapitato" è la diagnosi più utile in tale schermata, poiché lo stato "collegato ma mai recapitato" corrisponde esattamente all'aspetto di un token con ambito errato o di un recapito bloccato — e non è visibile altrove. La firma di ciascun recapito viene verificata prima di intraprendere qualsiasi azione.
È offerto ed è contrassegnato. GitHub Pages e GitLab Pages condividono l'infrastruttura del provider e i nomi host pubblici github.io e gitlab.io, e ciò costituisce un'impronta per i motori di ricerca — l'unica cosa che questa linea intende evitare. Per una rete a impronta zero, eseguite invece il deployment su un hosting isolato. Ovunque altrove, Pages è di prima classe.
Perché il suo piano gratuito è concesso in licenza solo per uso non commerciale. Deduciamo una destinazione dagli account che ha collegato laddove ciò sia sicuro, e Vercel è deliberatamente escluso da tale deduzione: il collegamento di un account non deve mai posizionare silenziosamente un sito commerciale dove la sua licenza non lo consente. Lo selezioni e funzionerà esattamente come gli altri.
Sì. Ogni distribuzione registra il commit pubblicato, quando è stata eseguita e come è terminata, e la scheda Distribuzione del sito mostra la cronologia con accanto l'URL attivo. Le distribuzioni vengono eseguite in background, pertanto la pagina si aggiorna al completamento della compilazione anziché farLa attendere davanti a un indicatore di caricamento.
Iniziate una prova di 14 giorni senza carta di credito, collegate GitHub o GitLab e indirizzate un sito verso un ramo. Pubblicate su un host edge o sul nostro hosting con sincronizzazione bidirezionale dei file.
Inizia gratis