Verziókezelés
Csatlakoztassa a munkához használt GitHub- vagy GitLab-fiókját, és telepítsen közvetlenül egy ágból: a Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps vagy AWS Amplify felületére — vagy saját felügyelt tárhelyünkre, ahol a tárhely és a webhely fájljai mindkét irányban szinkronban maradnak. Minden kapcsolat megjeleníti a szükséges jogosultságokat, a tárolás előtt ellenőrzésre kerül a szolgáltató API-jával szemben, és a Vault szolgáltatásban tárolódik. Bejelentkezhet GitHub vagy GitLab fiókkal is.
A kapcsolat egy olyan hitelesítési adat, amelyet Ön másnak ad át. A miénk megadja a követelményeit, mielőtt Ön létrehozná, tárolás előtt igazolja a működését, és mindkét oldalról visszavonható.
Mielőtt létrehozna egy tokent, elmondjuk, mire kell képesnek lennie és miért. Nincs átfogó hatókör csak azért, mert egyszerűbb volt azt kérni, és nincs utólagos szembesülés azzal, hogy többet akartunk, mint amennyit a feladat megkövetelt.
A token tárolása előtt meghívjuk a szolgáltató saját API-ját a megadott tokennel. A hibás, lejárt vagy nem megfelelő hatókörű tokent a rendszer már az űrlapnál elutasítja ahelyett, hogy elfogadná, megfelelőnek mutatná, majd az első valódi telepítéskor meghiúsulna.
Nem a kódunkban, nem egy környezeti fájlban, nem egy naplóban és nem a parancssorban. A használat pillanatában oldódik fel, az azt használó munkaterhelés által.
Kapcsoljon össze egy személyes fiókot egy szervezetével, vagy két szervezeti fiókot. Minden webhely kiválasztja, melyikből végezze a telepítést, így az ügyfél adattára és az öné soha nem oszt meg hitelesítési adatokat.
Nyolc felügyelt peremhálózati gazdagép és saját infrastruktúránk. A cél a webhely tulajdonsága, nem a kapcsolaté, így ugyanaz a tároló közzétehet egy ágat egy Pages gazdagépen, és egy másik webhely futhat a mi hardverünkön.
Korlátlan sávszélesség, engedélyezett kereskedelmi használat, és apex domainek kezelése ugyanannál a szolgáltatónál, amely általában az Ön DNS-zónáját kezeli. Ezen okok miatt ez az elsődleges célállomás, amelyhez fordulunk.
Cloudflare Pages tárhely →Tegye közzé közvetlenül abból a tárolóból, amelyben a kód már megtalálható. Megjelölve a Footprint-Free sorban, mivel a megosztott github.io infrastruktúra maga is digitális lábnyom.
GitHub Pages tárhely →A GitLab Pages, a Netlify, a Vercel, a Render, az Azure Static Web Apps és az AWS Amplify mind olyan célpontok, amelyekre ugyanazzal a kapcsolattal és ugyanazzal a telepítési előzménnyel irányíthat át egy webhelyet.
Statikus webhelytárhely →Teljes alkalmazás egy összeállított csomag helyett – WordPress, PHP, Node. Ez az a célhely, amely kétirányú szinkronizálást kap, így a gépen és a branchen lévő fájlok összhangban maradnak.
Menedzselt tárhely →A nem a mi tulajdonunkban lévő tárhelyen közzétett webhely szintén fogyasztja a keretet, és továbbra is megjelenik az Ön vezérlőpultján a telepítéseivel, az üzemidejével és a SEO-adataival együtt minden más mellett, amit Ön futtat.
Külső webhelyek kerete →A böngészőn belüli szerkesztő ugyanazokon a fájlokon dolgozik, amelyeket a kétirányú szinkronizálás visszaküld, így az irányítópultról végzett gyors javítás egy commit lesz az Ön ágán ahelyett, hogy olyan módosítássá válna, amelyet később senki sem talál.
A webszerkesztő →Kétirányú szinkronizálás
Kapcsolja be, és a webhely saját fájljai visszakerülnek az Ön ágába, míg az adott ágon lévő commitok visszakerülnek a webhelyre. Minden általunk hosztolt webhelyen, minden vonalon működik — az egyetlen követelmény, hogy az alatta lévő gép képes legyen futtatni a Git eszközt a fájljain, amit a szervertől kérdezünk le, nem pedig a csomagból feltételezünk.
Ön választja ki, hogy melyik könyvtár szinkronizálódjon, mivel a WordPress ügyfele a témáját szeretné nyomon követni, nem pedig negyvenezer magfájlt. És ki van kapcsolva, amíg Ön be nem kapcsolja: a szinkronizálás engedélyezése döntés valaki más tárhelyéről, és ezt a döntést a migrálás soha nem hozhatja meg Ön helyett.
Két mód, és a különbség az, hogy hol fut a build. Mindkettő ugyanott végződik: egy ref-nél, amelyet lekérünk és közzéteszünk, a commitot pedig a telepítéshez rögzítjük.
GitHub vagy GitLab, a Kapcsolatok alatt. A jogosultságok fel vannak sorolva a token létrehozása előtt, és a tárolás előtt ellenőrzésre kerül a szolgáltatónál.
Tulajdonos, adattár, ág, valamint az, hogy egy könyvtárat teszünk-e közzé, vagy lekérjük azt, amit a CI felépített. Ennek részeként regisztráljuk a push webhookot.
A kijelölt ágra történő leküldés (push) elindítja a telepítést, vagy igény szerint telepíthet a webhely Telepítés lapjáról. A buildek a háttérben futnak.
A közzétételi előzmények mutatják, hogy mi és mikor került közzétételre. Kapcsolja be a kétirányú szinkronizálást, és az itt végzett módosítások commitként jelennek meg a saját ágában.
Ha valami hiba történik
A látszólag kifogástalan, de semmit sem fogadó adattárkapcsolat a klasszikus észrevétlen hiba — nem megfelelő hatókörű token, a szolgáltatónál letiltott kézbesítés, vagy egy manuálisan eltávolított hook. Ez semmilyen más képernyőn nem látható, ezért az adattárkártya közvetlenül tartalmazza: mikor kézbesített utoljára a szolgáltató, és mit jelzett vissza.
A kézbesítések aláírását még a feldolgozásuk előtt ellenőrizzük az egyes szolgáltatók saját rendszere alapján, nem pedig egy olyan szerint, amelyről feltételeztük, hogy mindegyikre érvényes. A nem ellenőrizhető kézbesítést elutasítjuk és rögzítjük, nem pedig csendben figyelmen kívül hagyjuk.
Identitás
Az e-mail-cím és jelszó mellett a GitHub, a GitLab, a Google vagy a Microsoft segítségével is bejelentkezhet Zinn Digital®-fiókjába. A személyazonossági réteg hajtja végre a kézfogást; soha nem látjuk a szolgáltatói jelszavát, és a közösségi fiók meglévő Zinn®-fiókhoz történő kapcsolását továbbra is e-mailben kell megerősíteni.
A GitHub fiókkal való bejelentkezés és a GitHub telepítésekhez történő csatlakoztatása különálló döntések és különálló hitelesítési adatok. Az egyik elvégzése nem vonja maga után a másikat, és az egyik eltávolítása sem távolítja el a másikat.
GitHub és GitLab. Csatlakoztassa a fiókot, amellyel már dolgozik, és mi képesek leszünk a tárolóiból telepíteni, push webhookot regisztrálni rajtuk, és — ha szeretné — a webhely fájljait visszafelé is szinkronizálni. Mindkettő ugyanazon a csatlakoztatott fióki felületen megy keresztül, így az alábbiak mindegyike mindkettőre érvényes.
Igen, valamint a Google vagy a Microsoft fiókkal is. Az e-mail-cím és jelszó mellett a négy lehetőség bármelyikével bejelentkezhet Zinn Digital® fiókjába. Az identitásréteg kezeli a kézfogást, és mi soha nem látjuk a szolgáltatói jelszavát. A GitHubbal történő bejelentkezés elkülönül a GitHub telepítésekhez (deploys) való csatlakoztatásától — választhatja az egyiket, mindkettőt vagy egyiket sem.
Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps vagy AWS Amplify felületre statikus vagy felépített webhelyek esetén — vagy a saját felügyelt tárhelyünkre, ahol a repository és a webhely fájljai mindkét irányban szinkronban maradnak. Ön választja ki a webhely célhelyét; a repository-kapcsolat mindkét esetben azonos.
Bármelyik. Közzétételi módban az ágat úgy vesszük át, ahogy van, és közzétesszük az Ön által megadott könyvtárat. CI módban a szolgáltatója saját folyamata futtatja a build parancsot, és a kimenetet egy külön közzétételi ágba véglegesíti, amelyet aztán ugyanúgy lekérünk, mint bármely más referenciát. A második megoldás a saját CI-jében tartja a buildet, ahol a titkos adatai és a gyorsítótárazása már eleve megtalálhatók.
Alapértelmezés szerint igen — regisztrálunk egy webhookot a tárolóban, és az Ön által megjelölt ágra történő push elindít egy telepítést. Ezt kikapcsolhatja, és megtarthatja a webhookot, ami hasznosabb, mint amilyennek hangzik: a kézbesítés továbbra is rögzítésre kerül, így nyomon követheti a push-ok beérkezését, mielőtt engedélyezné számunkra a cselekvést.
A hardverünkön végzett módosítások commitokká válnak az Ön ágán, és az Ön ágán lévő commitok visszakerülnek a webhelyre. Mindaddig ki van kapcsolva, amíg Ön be nem kapcsolja, mivel a bekapcsolása egy valaki más adattárára vonatkozó döntés, és ezt nem hozzuk meg Ön helyett. Ön választja ki, hogy melyik könyvtár szinkronizálódjon — általában egy sablon vagy egy bővítmény, nem pedig negyvenezer WordPress magfájl.
Semmi sem íródik felül, és semmi sem kerül leküldésre. A szinkronizálás leáll, értesíti Önt arról, hogy a branch túllépett azon a commiton, amelyre támaszkodtunk, és megkérdezi, melyik oldalt szeretné — a tároló megtartását vagy a webhely megtartását. Egy olyan webhely, amely még soha nem szinkronizált, és egy olyan branchre mutat, amely már tartalmaz commitokat, szintén egy sajátos állapot, és ahelyett, hogy találgatná, melyik a helyes, rákérdez.
Mielőtt létrehozná a kapcsolatot, megmutatjuk a szükséges jogosultságokat, a megadásakor ellenőrizzük a tokent a szolgáltató saját API-jával szemben – így az érvénytelen vagy helytelen hatókörű token egyáltalán nem kerül tárolásra –, és csak ezután írjuk be a Vault környezetbe. Soha nem érinti a kódunkat, naplófájlunkat, környezeti fájlunkat vagy parancssorunkat. Vonja vissza a szolgáltatónál, vagy távolítsa el a kapcsolatot itt, amikor csak szeretné.
A tárolókártya mutatja, hogy a szolgáltató mikor kézbesített utoljára hozzánk, és mit közölt. A „Soha nem kézbesítve” a leghasznosabb diagnosztika ezen a képernyőn, mivel a „csatlakoztatva, de soha nem kézbesítve” állapot pontosan úgy néz ki, mint egy helytelen hatókörű token vagy egy blokkolt kézbesítés — és ez sehol máshol nem látható. Minden kézbesítés aláírását ellenőrizzük, mielőtt feldolgoznánk azt.
Elérhető és meg van jelölve. A GitHub Pages és a GitLab Pages közös szolgáltatói infrastruktúrát, valamint nyilvános github.io és gitlab.io gazdagépneveket használ, ez pedig keresőmotoros lábnyomot jelent – pont azt, aminek az elkerülésére ez a vonal szolgál. A lábnyommentes hálózat érdekében válasszon helyette izolált tárhelyen történő telepítést. Minden más esetben a Pages elsőrangú.
Mert az ingyenes csomagja kizárólag nem kereskedelmi használatra engedélyezett. Ahol ez biztonságos, a csatlakoztatott fiókokból következtetünk a célhelyre, és a Vercel szándékosan ki van zárva ebből a következtetésből — egy fiók csatlakoztatása soha nem helyezhet el csendben egy kereskedelmi webhelyet olyan helyre, amelyet a licence nem engedélyez. Válassza ki, és pontosan úgy fog működni, mint a többi.
Igen. Minden közzététel rögzíti az általa közzétett commitot, a futás időpontját és a befejezés módját, a webhely Közzététel lapja pedig megjeleníti az előzményeket a mellettük lévő élő URL-lel. A közzétételek a háttérben futnak, így az oldal az összeállítás befejezésekor frissül, ahelyett hogy egy forgó betöltésjelző előtt kellene várakoznia.
Indítson el egy bankkártya nélküli 14 napos próbaverziót, csatlakoztassa a GitHub vagy GitLab fiókot, és irányítson egy webhelyet egy ágra. Publikáljon edge kiszolgálóra, vagy a saját tárhelyünkre, a fájlok kétirányú szinkronizálásával.
Kezdés ingyen