Správa zdrojového kódu

Nasaďte z repozitáře, který již používáte – devět míst, kam jej umístit

Připojte účet GitHub nebo GitLab, ve kterém pracujete, a nasazujte přímo z větve: do Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps nebo AWS Amplify — nebo na náš vlastní spravovaný hosting, kde úložiště a soubory webu zůstávají synchronizovány v obou směrech. Každé připojení zobrazuje oprávnění, která vyžaduje, je před uložením ověřeno vůči API poskytovatele a uloženo v Vault. Můžete se také přihlásit pomocí GitHub nebo GitLab.

Commit procházející pipeline z repozitáře na živý web.
  • GitHub + GitLabPřipojte účet, který již máte
  • Devět cílůosm koncových hostitelů a navíc naše vlastní flotila
  • Obousměrná synchronizacekaždý web, každý řádek
  • Uloženo ve Vaultověřeno při vstupu, nikdy v protokolu
  • Token byl před uložením zkontrolovántoken s příliš širokým rozsahem oprávnění není nikdy schválen
  • Nahrát pro nasazenís ověřeným podpisem a volitelné
  • Vaše větev, vaše sestavenípublikujte adresář nebo spusťte vlastní CI
  • Čistě odpojitodstraníme přesně ten hook, který jsme vytvořili

Připojte se jednou a podívejte se, s čím souhlasíte

Připojení představuje přihlašovací údaje, které předáváte někomu jinému. To naše předem sdělí, co potřebuje, ještě před uložením ověří svou funkčnost a lze jej kdykoli zrušit z obou stran.

Oprávnění uvedená předem

Než vytvoříte token, sdělíme vám, co musí umět a proč. Žádný plošný rozsah jen proto, že bylo snazší o něj požádat, a žádné zjišťování po činu, že jsme chtěli víc, než bylo pro daný úkol potřeba.

Ověřeno u poskytovatele, nepřijato na pouhou důvěru

Před uložením vašeho tokenu zavoláme vlastní API poskytovatele. Chybný, prošlý nebo nesprávně vymezený token je odmítnut přímo ve formuláři, místo aby byl přijat, označen jako v pořádku a následně selhal při prvním skutečném nasazení.

Uloženo ve Vault a nikde jinde

Ne v našem kódu, ne v souboru prostředí, ne v protokolu a ne na příkazovém řádku. Vyřešeno v okamžiku použití, a to pracovní zátěží, která jej používá.

Více než jeden účet, vybraný pro každý web

Připojte osobní účet a účet organizace, případně dva účty organizací. Každý web si volí, ze kterého bude nasazovat, takže repozitář klienta a váš vlastní nikdy nesdílejí přihlašovací údaje.

Devět míst, kde může repozitář skončit

Osm spravovaných edge hostitelů a naše vlastní flotila. Cíl je vlastností webu, nikoli připojení, takže stejný repozitář může publikovat jednu větev na Pages hostitele a jiný web může běžet na našem hardwaru.

Cloudflare Pages

Neomezená šířka pásma, povolené komerční využití a správa apex domén u stejného poskytovatele, který obvykle spravuje vaši DNS zónu. Z těchto důvodů jde o první volbu, po které sáhneme.

Hosting Cloudflare Pages →

GitHub Pages

Publikujte přímo z repozitáře, ve kterém se kód již nachází. Označeno na řádku Footprint-Free, protože sdílená infrastruktura github.io sama o sobě představuje stopu.

Hosting GitHub Pages →

GitLab Pages, Netlify, Vercel a ostatní

GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps a AWS Amplify jsou cíle, na které můžete web nasměrovat se stejným připojením a stejnou historií nasazení.

Hosting statických stránek →

Náš vlastní spravovaný hosting

Kompletní aplikace namísto sestaveného balíčku — WordPress, PHP, Node. Toto je cílové umístění, které získává obousměrnou synchronizaci, takže soubory na serveru a ve větvi zůstávají v souladu.

Spravovaný hosting →

Weby na cizím edgi

Web publikovaný na hostingu, který nevlastníme, stále čerpá limit a nadále se zobrazuje na vašem ovládacím panelu se svými nasazeními, dobou provozu a daty SEO vedle všeho ostatního, co provozujete.

Limity externích webů →

Nebo jej upravte zde

Editor v prohlížeči pracuje se stejnými soubory, které obousměrná synchronizace odesílá zpět, takže se rychlá oprava z ovládacího panelu stane commitem ve Vaší větvi namísto změny, kterou později nikdo nedokáže najít.

Webový editor →

Obousměrná synchronizace

Váš repozitář a váš živý web v dokonalém souladu

Zapněte jej a vlastní soubory webu se odešlou zpět do vaší větve, zatímco commity v této větvi se vrátí zpět na web. Funguje to na každém webu, který hostujeme, na každém řádku — jediným požadavkem je, aby podkladový stroj dokázal spustit Git nad svými soubory, což se zjišťuje dotazem na server, namísto předpokládání z tarifu.

Vy sami si vybíráte, který adresář se synchronizuje, protože zákazník platformy WordPress chce sledovat svou šablonu, nikoli čtyřicet tisíc základních souborů. A tato funkce je vypnutá, dokud ji nezapnete: povolení synchronizace je rozhodnutí týkající se cizího repozitáře a migrace ho za vás nikdy nesmí učinit.

  • Úpravy na našem hardwaru se stanou commity ve vaší větvi
  • Commity ve vaší větvi se vrací na web
  • Synchronizujte jeden adresář — motiv, plugin — nikoli celý kořenový adresář dokumentů
  • Ve výchozím nastavení vypnuto, a to včetně všech již existujících webů
Soubor otevřený v editoru a stejný soubor zobrazený jako commit v repozitáři.

Publikujte adresář nebo jej nechte sestavit vlastním CI

Dva režimy, přičemž rozdíl spočívá v tom, kde probíhá sestavení. Oba končí na stejném místě: v referenci, kterou načteme a publikujeme, přičemž commit je zaznamenán k nasazení.

  • Režim publikování vezme vaši větev tak, jak je, a publikuje adresář, který určíte — prázdná hodnota znamená kořenový adresář repozitáře.
  • Režim CI spustí Váš příkaz pro sestavení ve vlastním kanálu Vašeho poskytovatele a výstup zapíše do samostatné větve pro publikování, kterou načítáme jako kteroukoli jinou referenci.
  • Větev, ze které se publikuje nasazení, je vždy výslovně pojmenována, nikdy to není „výchozí větev“ – výchozí se může změnit bez vašeho vědomí a historie, která nedokáže říci, ze které větve publikovala, není žádná historie.
  • Automatické nasazení je ve výchozím nastavení zapnuto a lze jej vypnout bez odstranění webhooku, takže můžete sledovat přicházející doručení dříve, než jim povolíte provést akci.
  • Každé nasazení zaznamenává svůj commit, svůj výsledek a svůj čas a běží na pozadí — stránka se aktualizuje po dokončení sestavení.
  • Odpojením se odstraní přesně ten webhook, který jsme vytvořili, podle jeho id, a nic jiného ve vašem repozitáři.

Z repozitáře na živý web

  1. Připojit účet

    GitHub nebo GitLab, v sekci Připojení. Oprávnění jsou uvedena před vytvořením tokenu a před uložením je token ověřen u poskytovatele.

  2. Nasměrujte web na repozitář

    Vlastník, repozitář, větev a to, zda publikujeme adresář, nebo načítáme to, co sestavil váš CI. V rámci toho zaregistrujeme webhook pro push.

  3. Zatlačte nebo stiskněte tlačítko

    Odeslání (push) do určené větve spustí nasazení, případně můžete nasadit na vyžádání z karty Nasazení daného webu. Sestavení probíhají na pozadí.

  4. Sledujte to a v případě potřeby znovu synchronizujte

    Historie nasazení zobrazuje, co bylo publikováno a kdy. Zapněte obousměrnou synchronizaci a úpravy, které zde provedete, se vrátí jako commity do vaší větve.

Když dojde k chybě

„Připojeno, ale nikdy nedoručeno“ je stav, o kterém vás skutečně budeme informovat

Připojení k repozitáři, které vypadá v pořádku a nic nepřijímá, je klasickým tichým selháním — token s nesprávným rozsahem, doručení zablokované u poskytovatele, webhook odstraněný ručně. Na žádné jiné obrazovce to není vidět, proto to karta repozitáře uvádí přímo: kdy vám poskytovatel naposledy doručil data a co bylo výsledkem.

Doručení jsou před provedením akce zkontrolována z hlediska podpisu, a to pomocí vlastního schématu každého poskytovatele, nikoli schématu, u kterého jsme předpokládali, že platí pro všechny. Doručení, které se nepodaří ověřit, je odmítnuto a zaznamenáno, nikoli tiše ignorováno.

  • Čas a zpráva o posledním doručení na kartě
  • Uvádí se „Nikdy nedoručeno“, neponechává se prázdné
  • Podpis byl ověřen pro každého poskytovatele před spuštěním čehokoli
  • Hák, který jsme vytvořili, je při odpojení odstraněn podle ID
Doručení webhooku přichází a je ověřováno předtím, než cokoli spustí.

Identita

Přihlaste se pomocí GitHub nebo GitLab — nebo Google, či Microsoft

Kromě e-mailové adresy a hesla se můžete ke svému účtu Zinn Digital® přihlásit pomocí služeb GitHub, GitLab, Google nebo Microsoft. Vrstva identity zajišťuje navázání spojení; heslo od vašeho poskytovatele nikdy nevidíme a propojení účtu ze sociální sítě se stávajícím účtem Zinn® musí být i nadále potvrzeno e-mailem.

Přihlášení pomocí GitHub a připojení GitHub pro nasazení jsou samostatná rozhodnutí a samostatné přihlašovací údaje. Provedení jednoho neznamená provedení druhého a odebrání jednoho neodebere druhé.

  • Přihlášení přes GitHub, GitLab, Google a Microsoft
  • Přístupové klíče a dvoufázové ověření na stejném účtu
  • Přihlašovací a nasazovací údaje zůstávají oddělené
Delegovaný přístup pro váš tým
Několik lidí přihlašujících se k jednomu účtu prostřednictvím různých poskytovatelů.

Často kladené otázky

Které poskytovatele správy verzí mohu připojit?

GitHub a GitLab. Připojte účet, ve kterém již pracujete, a my budeme moci nasazovat z jeho repozitářů, zaregistrovat na nich push webhook a — pokud si to přejete — synchronizovat soubory vašeho webu opačným směrem. Obojí probíhá přes stejné rozhraní připojeného účtu, takže vše níže uvedené platí pro obojí.

Mohu se přihlásit pomocí GitHub nebo GitLab?

Ano, a také pomocí Google nebo Microsoft. Vedle e-mailové adresy a hesla se můžete ke svému účtu Zinn Digital® přihlásit kteroukoli ze čtyř možností. Vrstva identity zajišťuje navázání spojení a my vaše heslo k poskytovateli nikdy neuvidíme. Přihlášení přes GitHub je oddělené od propojení GitHub pro nasazení — můžete využít jedno, obojí, nebo ani jedno.

Kde mohu nasadit repozitář?

Do Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps nebo AWS Amplify pro statický či sestavený web — nebo na náš vlastní spravovaný hosting, kde repozitář a soubory webu zůstávají synchronizovány v obou směrech. Cíl webu si volíte vy; propojení s repozitářem zůstává v obou případech stejné.

Můžete vytvořit můj web, nebo musí být již předem vytvořený?

Kterákoli z možností. V režimu publikování převezmeme větev tak, jak je, a publikujeme adresář, který určíte. V režimu CI spustí vlastní pipeline Vašeho poskytovatele Váš příkaz k sestavení a zapíše výstup do samostatné publikační větve, kterou pak stáhneme jako jakoukoli jinou referenci. Druhá možnost ponechává sestavení ve Vašem vlastním CI, kde se již nacházejí Vaše tajné klíče i mezipaměť.

Nasazuje se push automaticky?

Ve výchozím nastavení ano — v repozitáři zaregistrujeme webhook a push do Vámi určené větve spustí nasazení. Tuto funkci můžete vypnout a webhook si ponechat, což je užitečnější, než se zdá: doručení je stále zaznamenáváno, takže můžete sledovat příchod svých pushů dříve, než nám umožníte na ně reagovat.

Co je obousměrná synchronizace?

Úpravy provedené na našem hardwaru se stanou commity ve vaší větvi a commity ve vaší větvi se vrátí zpět na web. Funkce je vypnutá, dokud ji nezapnete, protože její zapnutí je rozhodnutím o cizím repozitáři a my ho za vás neučiníme. Sami si zvolíte, který adresář se bude synchronizovat — obvykle motiv nebo plugin, nikoli čtyřicet tisíc základních souborů WordPress.

Co se stane, pokud se změní obě strany?

Nic se nepřepisuje a nic se neodesílá. Synchronizace se zastaví, oznámí vám, že se větev posunula za commit, ze kterého jsme vycházeli, a zeptá se, kterou stranu chcete — zachovat repozitář, nebo zachovat web. Web, který se nikdy nesynchronizoval a odkazuje na větev, která již commity obsahuje, představuje také samostatný stav a namísto hádání, co je pravda, se raději zeptá.

Jak je chráněn můj přístupový token?

Před vytvořením připojení vám zobrazíme oprávnění, která vyžaduje, při zadání ověříme token vůči vlastnímu rozhraní API poskytovatele – neplatný nebo nesprávně vymezený token se tedy vůbec neuloží – a teprve poté jej zapíšeme do Vault. Nikdy se nedotkne našeho kódu, protokolu, souboru prostředí ani příkazového řádku. U poskytovatele jej můžete odvolat nebo zde připojení odebrat, kdykoli budete chtít.

Jak poznám, zda mé commity/pushe skutečně přijímáte?

Karta repozitáře ukazuje, kdy nám poskytovatel naposledy doručil data a co bylo jejich obsahem. „Nikdy nedoručeno“ je nejužitečnější diagnostický údaj na této obrazovce, protože stav „připojeno, ale nikdy nedoručeno“ přesně odpovídá tokenu s nesprávným rozsahem oprávnění nebo zablokovanému doručení — a nikde jinde to není vidět. Každé doručení je před zpracováním zkontrolováno na základě podpisu.

Mohu na lince Footprint-Free použít nasazení Pages?

Tato možnost je nabízena a je označena. GitHub Pages a GitLab Pages sdílejí infrastrukturu poskytovatele a veřejné názvy hostitelů github.io a gitlab.io, což představuje digitální stopu ve vyhledávačích — přesně to, čemu má tato řada zabránit. Pro síť zcela beze stopy nasaďte řešení raději na izolovaný hosting. Všude jinde představuje Pages prvotřídní volbu.

Proč musím Vercel vybrat výslovně?

Protože jeho bezplatná úroveň je licencována pouze pro nekomerční použití. Cíl odvozujeme z účtů, které jste propojili, pokud je to bezpečné, a Vercel je z tohoto odvozování záměrně vyloučen — propojení účtu nesmí nikdy v tichosti umístit komerční web někam, kde to jeho licence nepovoluje. Zvolte jej a bude fungovat přesně jako ostatní.

Mohu vidět, co bylo nasazeno a kdy?

Ano. Každé nasazení zaznamenává commit, který publikovalo, kdy proběhlo a jak skončilo, a na kartě Nasazení na webu se zobrazuje historie s živou adresou URL vedle ní. Nasazení běží na pozadí, takže se stránka aktualizuje po dokončení sestavení, místo aby Vás nutila čekat u indikátoru načítání.

Nasadit z vašeho repozitáře

Zahajte 14denní zkušební verzi bez platební karty, připojte GitHub nebo GitLab a nasměrujte web na větev. Publikujte na edge hostiteli nebo na našem vlastním hostingu s obousměrnou synchronizací souborů.

Začněte zdarma