Distribuzione con Zinnector®: collega, controlla, invia

Una volta che un progetto funziona in locale, quattro comandi consentono di trasferirlo su un sito live sull'hosting Zinn Digital®: effettuare l'accesso, collegare il progetto a uno slot di hosting, eseguire i controlli preliminari (pre-flight) e fare il push. Questo articolo esamina ciascuno di essi, ciò che mostrano e i comandi da utilizzare successivamente: nuovi deployment, cronologia dei deployment e log di compilazione.

Accedere con una chiave API

Crei una chiave nella dashboard sotto Impostazioni → Chiavi API, quindi:

zinnector login

La chiave viene digitata a una richiesta di conferma: non viene mai accettata direttamente sulla riga di comando, quindi non può finire nella cronologia della Sua shell o in un elenco di processi. In CI, la invii tramite pipe: echo "$ZINN_API_KEY" | zinnector login --profile ci, oppure imposti ZINNECTOR_TOKEN e salti del tutto il login. La chiave viene verificata prima di essere memorizzata, e salvata con permessi di file 600. zinnector whoami --scopes mostra a quale organizzazione ha effettuato l'accesso e quali permessi possiede la chiave; una chiave sandbox viene contrassegnata come tale.

Collegare il progetto a uno slot

zinnector link                                   # seleziona un sito da un elenco
zinnector link example.com --repo acme/site --branch main

link scrive l'ID del sito in zinnector.json e, a meno che non si passi --no-repo, connette il remote git del progetto al sito sulla piattaforma affinché un push ne avvii il deployment. Effettui il commit di zinnector.json: un collega che clona il repository effettuerà quindi il deployment nello stesso posto senza bisogno di istruzioni. Non contiene alcun segreto.

Eseguire i controlli preliminari

zinnector check

Questo è il comando per cui esiste la CLI. Confronta il Suo progetto con lo slot su cui sta per essere distribuito e mostra ogni discrepanza, insieme a ogni confronto che non è stato possibile effettuare:

• Versione di PHP, con un divario di major version classificato come alto perché danneggia quasi certamente un sito, e un divario di minor version classificato più in basso, poiché classificare tutto come critico induce le persone a ignorare l'avviso.
• Se lo slot può passare alla versione su cui ha effettuato la compilazione, se il PHP dello slot ha superato la fine del ciclo di vita e se la macchina ha applicato la versione o se ne ha soltanto ricevuto l'istruzione.
• La dimensione e il numero di file del Suo progetto rispetto allo spazio su disco e ai margini di inode effettivamente rimasti sullo slot: un albero di WordPress può esaurire i file pur rimanendo ampiamente al di sotto del limite di spazio su disco.
• Le versioni di WordPress su ciascun lato, se lo slot ha terminato il provisioning e se è connesso un repository su cui effettuare il push.

Avvisa; non blocca mai. Ogni riscontro è ignorabile con zinnector push --force, poiché Lei conosce aspetti del Suo sito che uno strumento di verifica non può conoscere. Un confronto che non è stato possibile effettuare viene segnalato come sconosciuto, mai come superato, e il riepilogo indica sempre quanti ne sono stati rilevati. Per impostazione predefinita, la versione locale di PHP è quella dichiarata in zinnector.json; --probe avvia invece il runtime locale e lo misura direttamente. --strict esce con codice diverso da zero anche in presenza di elementi sconosciuti, che è ciò che richiede un gate di CI.

Push

zinnector push

push esegue i controlli preliminari, invia i Suoi commit, attiva il deployment e ne monitora il completamento, stampando lo stato finale e il commit distribuito. --dry-run esegue tutto tranne il deployment; --no-wait lo attiva ed esce; --no-git distribuisce tutto ciò che la piattaforma possiede già senza inviare modifiche. Se il commit distribuito non è quello appena inviato, lo segnala.

In caso di problemi

zinnector deploys example.com        # cronologia dei deployment — stato, commit, attivatore, messaggio
zinnector logs example.com --build   # il log di compilazione del deployment più recente
zinnector logs example.com --error   # il log degli errori del sito
zinnector deploy example.com         # ridistribuisce ciò che la piattaforma possiede già
zinnector ai "why is my deploy failing?"

zinnector ai viene eseguito sulla piattaforma a livello del Suo account, quindi può accedere alla stessa cronologia dei deployment e agli stessi log. Dall'interno di un progetto invia la struttura del progetto stesso (nomi di directory, versioni e ID del sito) e mai i contenuti dei file.

Articoli correlati

• Guida introduttiva · Sviluppo locale · Riferimento comandi · Risoluzione dei problemi