Implementare cu Zinnector®: link, verificare, trimite

Odată ce un proiect rulează local, patru comenzi îl duc pe un site live pe găzduirea Zinn Digital®: autentificarea, asocierea proiectului la un slot de găzduire, citirea verificării prealabile (pre-flight) și publicarea (push). Acest articol parcurge fiecare comandă în parte, ce afișează și comenzile pe care le utilizați ulterior — redeploierile, istoricul deploierilor și jurnalele de compilare.

Autentificarea cu o cheie API

Creați o cheie în panoul de control, la Settings → API keys, apoi:

zinnector login

Cheia este introdusă la o solicitare — nu este acceptată niciodată în linia de comandă, astfel încât să nu poată ajunge în istoricul shell-ului sau într-o listă de procese. În CI, trimiteți-o prin pipe: echo "$ZINN_API_KEY" | zinnector login --profile ci, sau setați ZINNECTOR_TOKEN și săriți complet peste login. Cheia este verificată înainte de a fi stocată și este salvată cu permisiunea de fișier 600. zinnector whoami --scopes arată organizația în care sunteți autentificat și permisiunile pe care le are cheia; o cheie de tip sandbox este etichetată ca atare.

Asocierea proiectului la un slot

zinnector link                                   # alegeți un site dintr-o listă
zinnector link example.com --repo acme/site --branch main

link scrie ID-ul site-ului în zinnector.json și, cu excepția cazului în care transmiteți --no-repo, conectează repository-ul de git al proiectului la site-ul de pe platformă, astfel încât o operațiune de push să efectueze deploierea. Salvați în commit fișierul zinnector.json: un coleg care clonează repository-ul va face apoi deploierea în același loc, fără a fi nevoie să i se indice acest lucru. Acesta nu conține nicio informație secretă.

Citirea verificării prealabile (pre-flight)

zinnector check

Aceasta este comanda pentru care există CLI-ul. Ea compară proiectul dumneavoastră cu slotul pe care urmează să fie deplasat și afișează fiecare neconcordanță — precum și fiecare comparație pe care nu a putut o efectua:

• Versiunea PHP, cu o diferență de versiune majoră clasificată drept ridicată, deoarece întrerupe în mod sigur funcționarea unui site, și o diferență minoră clasificată mai jos, deoarece clasificarea a tot ceea ce este critic drept important îi învață pe oameni să ignore avertismentul.
• Dacă slotul poate trece la versiunea pe care ați folosit-o la compilare, dacă versiunea PHP a slotului a ieșit din ciclul de viață (end of life) și dacă mașina a aplicat versiunea sau doar a primit instrucțiuni în acest sens.
• Dimensiunea proiectului și numărul de fișiere raportate la spațiul de stocare disponibil și la numărul de inode-uri rămase efectiv pe slot — un arbore WordPress poate rămâne fără fișiere deși se află mult sub limita de disc.
• Versiunile WordPress de pe fiecare parte, dacă slotul a finalizat procesul de provisioning și dacă un repository este conectat pentru a efectua push-ul.

Aceasta emite avertismente, dar nu blochează niciodată. Fiecare constatăre poate fi ignorată folosind zinnector push --force, deoarece cunoașteți detalii despre propriul site pe care un program de verificare nu le are. O comparație care nu a putut fi efectuată este raportată ca fiind necunoscută (unknown), niciodată ca fiind reușită, iar sumarul menționează întotdeauna câte au existat. În mod implicit, versiunea PHP locală este cea declarată în zinnector.json; --probe pornește mediul de execuție local și o măsoară în schimb. --strict returnează un cod de ieșire diferit de zero și pentru necunoscute, exact ceea ce solicită o poartă CI (CI gate).

Publicarea (Push)

zinnector push

push rulează verificarea prealabilă, trimite commit-urile dumneavoastră, declanșează deploierea și o monitorizează până la finalizare, afișând starea finală și commit-ul deplasat. --dry-run face totul cu excepția deploierii; --no-wait o declanșează și iese; --no-git deplasează tot ceea ce platforma are deja, fără a efectua push. Dacă commit-ul deplasat nu este cel care tocmai a fost trimis, acest lucru este semnalat.

Când ceva nu funcționează corect

zinnector deploys example.com        # istoricul deploierilor — stare, commit, declanșator, mesaj
zinnector logs example.com --build   # jurnalul de compilare pentru cea mai recentă deploiere
zinnector logs example.com --error   # jurnalul de erori al site-ului
zinnector deploy example.com         # redeploierea conținutului existent pe platformă
zinnector ai "why is my deploy failing?"

zinnector ai rulează pe platformă în cadrul contului dumneavoastră, astfel încât poate vedea același istoric de deploieri și aceleași jurnale. Din interiorul unui proiect, trimite structura acestuia — denumirile directoarelor, versiunile și ID-ul site-ului — și niciodată conținutul fișierelor.

Resurse conexe

• Noțiuni de bază · Dezvoltare locală · Referință pentru comenzi · Depanare