Controlul sursei
Conectați contul GitHub sau GitLab în care lucrați și implementați direct dintr-o ramură: pe Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps sau AWS Amplify — ori pe propriul nostru hosting gestionat, unde depozitul și fișierele site-ului rămân sincronizate în ambele direcții. Fiecare conexiune afișează privilegiile de care are nevoie, este verificată prin API-ul furnizorului înainte de a fi stocată și se află în Vault. De asemenea, vă puteți conecta cu GitHub sau GitLab.
O conexiune reprezintă o acreditare pe care o transmiteți altcuiva. A noastră specifică cerințele înainte de creare, demonstrează că funcționează înainte de stocare și poate fi revocată de oricare dintre părți.
Înainte de a crea un token, vă spunem ce trebuie să poată face și de ce. Fără permisiuni generale doar pentru că a fost mai ușor de cerut și fără a descoperi ulterior că am cerut mai mult decât era necesar pentru sarcină.
Apelăm propriul API al furnizorului cu tokenul dumneavoastră înainte de a-l stoca. Un token greșit, expirat sau cu un domeniu de aplicare incorect este refuzat direct în formular, în loc să fie acceptat, afișat ca funcțional și să eșueze la prima implementare reală.
Nu în codul nostru, nu într-un fișier de mediu, nu într-un jurnal și nu pe o linie de comandă. Rezolvat în momentul în care este utilizat, de către sarcina de lucru care îl folosește.
Conectați un cont personal și unul de organizație, sau două conturi de organizație. Fiecare site alege din care să implementeze, astfel încât depozitul unui client și al dumneavoastră să nu partajeze niciodată aceleași date de conectare.
Opt gazde edge gestionate și propria noastră flotă. Destinația este o proprietate a site-ului, nu a conexiunii, astfel încât același depozit poate publica o ramură pe o gazdă Pages, iar un alt site poate rula pe hardware-ul nostru.
Lățime de bandă nelimitată, utilizare comercială permisă și domenii apex gestionate la același furnizor care de obicei găzduiește zona dumneavoastră DNS. Din aceste motive, este prima opțiune la care apelăm.
Găzduire Cloudflare Pages →Publicați direct din depozitul în care se află deja codul. Marcat pe linia Footprint-Free, deoarece infrastructura partajată github.io reprezintă ea însăși o amprentă.
Găzduire GitHub Pages →GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps și AWS Amplify sunt toate destinații către care puteți direcționa un site, cu aceeași conexiune și același istoric de implementare.
Găzduire de site-uri statice →O aplicație completă, mai degrabă decât un pachet compilat — WordPress, PHP, Node. Aceasta este destinația care beneficiază de sincronizare bidirecțională, astfel încât fișierele de pe server și din ramură să rămână sincronizate.
Găzduire administrată →Un site publicat pe o găzduire care nu ne aparține consumă în continuare din cotă și continuă să apară în tabloul dumneavoastră de bord cu implementările, timpul de funcționare și datele sale SEO, alături de tot ceea ce gestionați.
Alocări pentru site-uri externe →Editorul din browser funcționează pe aceleași fișiere pe care sincronizarea bidirecțională le trimite înapoi, astfel încât o remediere rapidă din tabloul de bord devine un commit pe ramura dumneavoastră, în loc de o modificare pe care nimeni nu o mai poate găsi ulterior.
Editorul web →Sincronizare bidirecțională
Activați această opțiune și fișierele proprii ale site-ului sunt trimise prin commit înapoi în branch-ul dumneavoastră, în timp ce commit-urile de pe acel branch revin pe site. Funcționează pe fiecare site pe care îl găzduim, pe fiecare linie — singura cerință este ca serverul de bază să poată rula Git pe fișierele sale, lucru care este solicitat serverului, nu presupus din plan.
Dumneavoastră alegeți ce director se sincronizează, deoarece un client WordPress dorește ca tema sa să fie urmărită, nu patruzeci de mii de fișiere de bază. Și rămâne dezactivat până când îl activați: activarea unei sincronizări este o decizie cu privire la depozitul altcuiva, iar o migrare nu trebuie să ia niciodată această decizie în locul dumneavoastră.
Două moduri, iar diferența constă în locul în care rulează compilarea. Ambele se termină în același loc: o referință pe care o preluăm și o publicăm, cu commitul înregistrat pentru implementare.
GitHub sau GitLab, sub Conexiuni. Privilegiile sunt listate înainte de a crea tokenul și acesta este verificat la furnizor înainte de a fi stocat.
Proprietar, depozit, ramură și dacă publicăm un director sau preluăm ceea ce a construit CI-ul dumneavoastră. Înregistrăm webhook-ul de push ca parte a acestui proces.
O trimitere (push) către ramura desemnată pornește o implementare, sau puteți implementa la cerere din fila Implementare a site-ului. Compilările rulează în fundal.
Istoricul implementării arată ce s-a publicat și când. Activați sincronizarea bidirecțională, iar modificările pe care le efectuați aici vor reveni ca proceduri commit pe ramura dumneavoastră.
Când ceva nu merge bine
O conexiune la depozit care pare funcțională și nu primește nimic este eșecul silențios clasic — un token cu domeniul de aplicare greșit, o livrare blocată la furnizor, un hook pe care cineva l-a eliminat manual. Este invizibil pe orice alt ecran, așa că respectivul card al depozitului îl afișează direct: când a livrat furnizorul ultima dată către noi și ce a transmis.
Livrările sunt verificate prin semnătură înainte de a acționa asupra lor, folosind schema proprie a fiecărui furnizor, mai degrabă decât una despre care am presupus că se aplică tuturor. O livrare care nu este verificată este refuzată și înregistrată, nu ignorată în mod discret.
Identitate
Pe lângă o adresă de e-mail și o parolă, vă puteți conecta la contul dumneavoastră Zinn Digital® cu GitHub, GitLab, Google sau Microsoft. Stratul de identitate gestionează protocolul de conectare (handshake); nu vedem niciodată parola de la furnizorul dumneavoastră, iar asocierea unui cont social la un cont Zinn® existent trebuie în continuare confirmată prin e-mail.
Conectarea cu GitHub și conectarea GitHub pentru implementări sunt decizii separate și acreditări separate. Efectuarea uneia nu o realizează pe cealaltă, iar eliminarea uneia nu o elimină pe cealaltă.
GitHub și GitLab. Conectați contul în care lucrați deja și noi putem implementa din depozitele acestuia, putem înregistra un webhook de push pe ele și — dacă doriți — putem sincroniza fișierele site-ului dumneavoastră înapoi în celălalt sens. Ambele trec prin aceeași conexiune de cont asociat, așa că tot ce urmează este valabil pentru oricare dintre ele.
Da, și cu Google sau Microsoft. Pe lângă o adresă de e-mail și o parolă, vă puteți conecta la contul Zinn Digital® cu oricare dintre cele patru opțiuni. Nivelul de identitate gestionează protocolul de conectare (handshake), iar noi nu vedem niciodată parola furnizorului dumneavoastră. Conectarea cu GitHub este un proces separat de conectarea GitHub pentru implementări (deploys) — puteți alege oricare dintre ele, pe ambele sau pe niciuna.
Către Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps sau AWS Amplify pentru un site static sau compilat — ori pe propriul nostru serviciu de găzduire administrată, unde depozitul și fișierele site-ului rămân sincronizate în ambele direcții. Dumneavoastră alegeți destinația pentru site; conexiunea depozitului este aceeași în ambele cazuri.
Oricare. În modul de publicare, preluăm ramura așa cum este și publicăm directorul pe care îl specificați. În modul CI, propriul pipeline al furnizorului dumneavoastră rulează comanda de compilare și trimite rezultatul către o ramură de publicare separată, pe care o preluăm apoi ca pe orice altă referință. A doua opțiune vă păstrează procesul de compilare în propriul CI, unde se află deja secretele și datele dumneavoastră din memoria cache.
În mod implicit, da — înregistrăm un webhook în depozit, iar un push către ramura pe care ați indicat-o declanșează o implementare. Puteți dezactiva această opțiune și păstra webhookul, ceea ce este mai util decât pare: livrarea este încă înregistrată, astfel încât puteți urmări sosirea push-urilor înainte de a ne permite să acționăm asupra lor.
Modificările efectuate pe hardware-ul nostru devin commit-uri pe branch-ul dumneavoastră, iar commit-urile de pe branch-ul dumneavoastră revin pe site. Este dezactivat până când îl activați, deoarece activarea sa este o decizie privind depozitul altcuiva și nu o vom lua în locul dumneavoastră. Dumneavoastră alegeți ce director se sincronizează — de obicei o temă sau un modul, nu patruzeci de mii de fișiere de bază WordPress.
Nimic nu este suprascris și nimic nu este trimis prin push. Sincronizarea se oprește, vă informează că ramura a avansat dincolo de commitul pe care ne-am bazat și vă întreabă ce parte doriți — să păstrați depozitul sau să păstrați site-ul. Un site care nu s-a sincronizat niciodată și indică o ramură care are deja commituri este, de asemenea, o stare de sine stătătoare, iar sistemul întreabă în loc să ghicească care este adevărul.
Vă arătăm privilegiile de care are nevoie conexiunea înainte de a o crea, verificăm tokenul în raport cu API-ul propriu al furnizorului la introducere — astfel încât un token nevalid sau cu un domeniu incorect să nu fie stocat deloc — și abia apoi îl scriem în Vault. Acesta nu atinge niciodată codul nostru, un jurnal, un fișier de mediu sau o linie de comandă. Revocați-l la furnizor sau eliminați conexiunea de aici, oricând doriți.
Cardul depozitului arată când a trimis furnizorul ultima dată către noi și ce a transmis. „Niciodată livrat” este cel mai util diagnostic de pe acel ecran, deoarece „conectat, dar niciodată livrat” este exact modul în care arată un token cu domeniu de aplicare incorect sau o livrare blocată — și este invizibil oriunde altundeva. Fiecare livrare are semnătura verificată înainte de a acționa pe baza acesteia.
Este oferit și este semnalat. GitHub Pages și GitLab Pages împart infrastructura furnizorului și numele de gazdă publice github.io și gitlab.io, iar aceasta este o amprentă (footprint) — singurul lucru pe care această linie există pentru a-l evita. Pentru o rețea fără amprentă (zero-footprint), implementați în schimb pe o găzduire izolată. Peste tot în altă parte, Pages este de primă clasă.
Deoarece nivelul său gratuit este licențiat exclusiv pentru utilizare necomercială. Deducem o destinație din conturile pe care le-ați conectat acolo unde acest lucru este sigur, iar Vercel este exclus în mod deliberat din această deducție — conectarea unui cont nu trebuie niciodată să plaseze în mod discret un site comercial undeva unde licența sa nu permite. Alegeți-l și funcționează exact ca celelalte.
Da. Fiecare implementare înregistrează commitul publicat, momentul în care a rulat și modul în care s-a finalizat, iar fila Implementare a site-ului afișează istoricul alături de adresa URL activă. Implementările rulează în fundal, astfel încât pagina se actualizează pe măsură ce compilarea este finalizată, în loc să vă lase în așteptare cu o animație de încărcare.
Începeți o perioadă de probă de 14 zile fără card, conectați GitHub sau GitLab și direcționați un site către o ramură. Publicați pe o gazdă edge sau pe propria noastră găzduire, cu sincronizarea fișierelor în ambele sensuri.
Începeți gratuit