Kontrol ng source
Ikonekta ang account sa GitHub o GitLab kung saan kayo nagtatrabaho at mag-deploy nang direkta mula sa isang branch: sa Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps, o AWS Amplify — o sa aming sariling pinamamahalaang hosting, kung saan ang repository at ang mga file ng site ay nananatiling naka-sync sa parehong direksyon. Ipinapakita ng bawat koneksyon ang mga pribilehiyong kailangan nito, sinusuri laban sa API ng provider bago ito iimbak, at nananatili sa Vault. Maaari din kayong mag-sign in gamit ang GitHub o GitLab.
Ang koneksyon ay isang kredensyal na ibinibigay ninyo sa ibang tao. Sinasabi ng aming serbisyo kung ano ang kailangan nito bago ninyo ito buuin, pinapatunayang gumagana ito bago ito iimbak, at maaaring bawiin mula sa alinmang panig.
Bago kayo gumawa ng token, sinasabi namin sa inyo kung ano ang dapat nitong magawa at kung bakit. Walang panlahatang saklaw dahil lang mas madali itong hingin, at walang pagtuklas pagkatapos ng pangyayari na mas marami pala kaming ninais kaysa sa kailangan ng trabaho.
Tinatawagan namin ang sariling API ng provider gamit ang inyong token bago ito iimbak. Ang mali, nag-expire, o maling saklaw na token ay tinatanggihan sa form sa halip na tanggapin, ipakita bilang maayos, at mabigo sa unang totoong pag-deploy.
Wala sa aming code, wala sa isang environment file, wala sa isang log, at wala sa isang command line. Nalulutas sa sandaling ginagamit ito, sa pamamagitan ng workload na gumagamit nito.
Magkonekta ng personal na account at ng isang organisasyon, o ng dalawang organisasyon. Pinipili ng bawat site kung alin ang pagde-deployan nito, kaya hindi kailanman magbabahagi ng kredensyal ang repository ng kliyente at ang sa iyo.
Walong pinamamahalaang edge host at ang sarili naming fleet. Ang destinasyon ay isang katangian ng site, hindi ng koneksyon, kaya ang parehong repository ay maaaring mag-publish ng isang branch sa isang Pages host at ang isa pang site ay maaaring gumana sa aming hardware.
Walang limitasyong bandwidth, pinapayagan ang komersyal na paggamit, at mga apex domain na pinangangasiwaan sa parehong provider na karaniwang naglalaman ng iyong DNS zone. Ito ang unang destinasyong aming pinipili para sa mga dahilang iyon.
Cloudflare Pages hosting →Mag-publish nang direkta mula sa repository kung saan naroroon na ang code. Minarkahan sa linyang Footprint-Free, dahil ang ibinabahaging imprastraktura ng github.io ay mismong isang bakas.
GitHub Pages hosting →Ang GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps, at AWS Amplify ay pawang mga destinasyon kung saan maaari mong ituro ang isang site, gamit ang parehong koneksyon at parehong kasaysayan ng pag-deploy.
Pangangasiwa ng static site →Isang buong application sa halip na isang binuong bundle — WordPress, PHP, Node. Ito ang destinasyon na nakakakuha ng two-way sync, kaya ang mga file sa box at sa branch ay nananatiling magkatugma.
Pinapamahalaang hosting →Ang isang site na na-publish sa isang host na hindi namin pagmamay-ari ay gumagamit pa rin ng allowance at lumalabas pa rin sa iyong dashboard kasama ang mga deploy nito, ang uptime nito, at ang data ng SEO nito katabi ng lahat ng iba pang pinapatakbo mo.
Mga alokasyon para sa panlabas na site →Gumagana ang in-browser editor sa parehong mga file na ibinabalik ng two-way sync, kaya ang mabilisang pag-aayos mula sa dashboard ay nagiging commit sa iyong branch sa halip na isang pagbabago na walang makakahanap sa ibang pagkakataon.
Ang web editor →Two-way na pag-sync
I-on ito at ang sariling mga file ng site ay mako-commit pabalik sa iyong branch, habang ang mga commit sa branch na iyon ay babalik sa site. Gumagana ito sa bawat site na aming hino-host, sa bawat linya — ang tanging kailangan ay kaya ng makina sa ilalim na magpatakbo ng Git laban sa mga file nito, na hinihiling sa server sa halip na ipagpalagay mula sa plano.
Kayo ang pumipili kung aling directory ang magsi-sync, dahil nais ng isang customer ng WordPress na masubaybayan ang kanilang tema at hindi ang apatnapung libong pangunahing file. At ito ay naka-off hanggang sa i-on ninyo ito: ang pagpapagana ng sync ay isang desisyon tungkol sa repository ng ibang tao, at hindi kailanman dapat magdesisyon ang isang migrasyon para sa inyo.
Dalawang mode, at ang pagkakaiba ay kung saan tumatakbo ang build. Parehong nagtatapos sa iisang lugar: isang ref na kinukuha at inilalathala namin, na may commit na naitala laban sa deploy.
GitHub o GitLab, sa ilalim ng Mga Koneksyon. Nakalista ang mga pribilehiyo bago mo gawin ang token at sinusuri ito laban sa provider bago ito iimbak.
May-ari, repository, branch, at kung magpa-publish ba kami ng directory o kukunin ang binuo ng iyong CI. Inirerehistro namin ang push webhook bilang bahagi nito.
Ang pag-push sa itinalagang branch ay nagpapasimula ng pag-deploy, o maaari kayong mag-deploy on demand mula sa tab na Deploy ng site. Tumatakbo ang mga build sa background.
Ipinapakita ng history ng pag-deploy kung ano ang na-publish at kailan. I-on ang two-way sync at ang mga pagbabagong gagawin mo rito ay babalik bilang mga commit sa iyong branch.
Kapag may mali
Ang isang koneksyon sa repository na mukhang maayos ngunit walang natatanggap ay ang klasikong tahimik na pagkabigo — isang token na may maling scope, isang paghahatid na na-block sa provider, isang hook na manu-manong inalis ng isang tao. Hindi ito nakikita sa bawat iba pang screen, kaya direkta itong ipinapakita ng card ng repository: kung kailan huling naghatid ang provider sa atin, at kung ano ang sinabi nito.
Sinusuri ang lagda ng mga paghahatid bago kami magsagawa ng aksyon sa mga ito, gamit ang sariling pamamaraan ng bawat provider sa halip na isang inakala naming naaangkop sa lahat. Ang isang paghahatid na hindi ma-verify ay tinatanggihan at itinatala, hindi tahimik na binabalewala.
Pagkakakilanlan
Kasabay ng email address at password, maaari kang mag-sign in sa iyong Zinn Digital® account gamit ang GitHub, GitLab, Google, o Microsoft. Ang identity layer ang nagpapatakbo ng handshake; hindi namin kailanman nakikita ang iyong password sa provider, at ang pag-link ng social account sa isang umiiral nang Zinn® account ay kailangan pa ring kumpirmahin sa pamamagitan ng email.
Ang pag-sign in gamit ang GitHub at ang pagkokonekta ng GitHub para sa mga deploy ay magkahiwalay na desisyon at magkahiwalay na kredensyal. Ang paggawa sa isa ay hindi ginagawa ang isa pa, at ang pag-alis sa isa ay hindi nag-aalis sa isa pa.
GitHub at GitLab. Ikonekta ang account kung saan ka na nagtatrabaho at maaari kaming mag-deploy mula sa mga repository nito, magrehistro ng push webhook sa mga ito, at — kung nais mo — i-sync pabalik ang mga file ng iyong site sa kabilang direksyon. Parehong dumadaan ang dalawa sa iisang koneksyon ng nakakonektang account, kaya totoo ang lahat ng nasa ibaba para sa alinman sa dalawa.
Oo, at sa pamamagitan ng Google o Microsoft. Kasabay ng isang email address at isang password, maaari kayong mag-sign in sa inyong Zinn Digital® account gamit ang alinman sa apat. Pinapangasiwaan ng identity layer ang handshake at kailanman ay hindi namin nakikita ang password ng inyong provider. Ang pag-sign in gamit ang GitHub ay hiwalay sa pagkokonekta ng GitHub para sa mga deploy — maaari ninyong gawin ang alinman dito, pareho, o wala sa alinman.
Sa Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps o AWS Amplify para sa static o binuong site — o sa aming sariling pinapamahalaang hosting, kung saan nananatiling naka-sync sa magkabilang direksyon ang repository at ang mga file ng site. Kayo ang pipili ng patutunguhan para sa site; pareho lang ang koneksyon ng repository sa alinmang paraan.
Alinman sa dalawa. Sa publish mode, kinukuha namin ang branch kung ano ito at inilalathala ang direktoryo na inyong tinukoy. Sa CI mode, ang sariling pipeline ng inyong provider ang nagpapatakbo ng inyong build command at nagko-commit ng output sa isang hiwalay na publish branch, na kinukuha namin pagkatapos tulad ng iba pang ref. Pinapanatili ng ikalawa ang inyong build sa sarili ninyong CI, kung saan naroon na ang inyong mga lihim at caching.
Bilang default, oo — nagrerehistro kami ng webhook sa repository at ang push sa branch na iyong itinalaga ay nagpapasimula ng deploy. Maaari mo itong i-off at panatilihin ang webhook, na mas kapaki-pakinabang kaysa sa inaakala: naitatala pa rin ang delivery, kaya maaari mong subaybayan ang pagdating ng iyong mga push bago mo kami payagang kumilos sa mga ito.
Ang mga pag-edit na ginawa sa aming hardware ay nagiging mga commit sa iyong branch, at ang mga commit sa iyong branch ay babalik sa site. Naka-off ito hanggang sa i-on mo ito, dahil ang pag-on nito ay isang desisyon tungkol sa repository ng ibang tao at hindi namin iyon gagawin para sa iyo. Ikaw ang pumipili kung aling directory ang magsi-sync — kadalasan ay isang tema o isang plugin, hindi apatnapung libong mga core file ng WordPress.
Walang na-o-overwrite at walang pinu-push. Humihinto ang pag-sync, ipinapaalam sa inyo na lumampas na ang branch sa commit kung saan tayo nagbase, at nagtatanong kung aling panig ang gusto ninyo — panatilihin ang repository, o panatilihin ang site. Ang isang site na hindi pa kailanman na-sync at nakaturo sa isang branch na mayroon nang mga commit ay sarili rin nitong estado, at nagtatanong ito sa halip na hulaan kung alin ang totoo.
Ipinapakita namin sa inyo ang mga pribilehiyong kailangan ng koneksyon bago ninyo ito buuin, sinusuri ang token laban sa mismong API ng provider sa oras ng pagpasok — upang ang token na di-wasto o may maling saklaw ay hindi kailanman maiimbak — at saka lamang ito isinusulat sa Vault. Hindi nito kailanman nahahawakan ang aming code, isang log, isang environment file, o isang command line. Bawiin ito sa provider o alisin ang koneksyon dito, kailan ninyo man gusto.
Ipinapakita ng card ng repository kung kailan huling naghatid sa amin ang provider at kung ano ang sinabi nito. Ang "Hindi kailanman naihatid" ang pinakakapaki-pakinabang na diagnostic sa screen na iyon, dahil ang "nakakonekta ngunit hindi kailanman naihatid" ay eksaktong hitsura ng isang token na may maling scope o isang naharang na paghahatid — at hindi ito makikita saanman. Bawat paghahatid ay sinusuri ang lagda bago kami kumilos dito.
Inaalok ito at may marka. Ang GitHub Pages at GitLab Pages ay nagbabahagi ng imprastruktura ng provider at mga pampublikong hostname ng github.io at gitlab.io, at iyon ay isang footprint para sa mga search engine — ang mismong bagay na umiiral ang linyang iyon upang iwasan. Para sa isang network na walang footprint, mag-deploy sa nakahiwalay na hosting sa halip. Sa lahat ng iba pang sitwasyon, ang Pages ay primera-klase.
Dahil ang libreng tier nito ay lisensyado para sa hindi pang-komersyal na paggamit lamang. Naghihinuha kami ng destinasyon mula sa mga account na ikinonekta mo kung saan iyon ay ligtas, at ang Vercel ay sadyang ibinukod mula sa hinuha na iyon — ang pagkokonekta ng account ay hindi dapat kailanman tahimik na maglagay ng komersyal na site sa isang lugar na hindi pinapahintulutan ng lisensya nito. Piliin ito at gagana ito nang eksakto tulad ng iba.
Oo. Itinatala ng bawat deploy ang commit na na-publish nito, kung kailan ito tumakbo, at kung paano ito natapos, at ipinapakita ng tab na Deploy ng site ang history kasama ang live na URL sa tabi nito. Tumatakbo ang mga deploy sa background, kaya nag-a-update ang page habang nakukumpleto ang build sa halip na paghintayin kayo sa isang spinner.
Magsimula ng 14 na araw na libreng pagsubok nang walang card, ikonekta ang GitHub o GitLab, at ituro ang isang site sa isang branch. Mag-publish sa isang edge host, o sa sarili naming hosting na may mga file na nagsi-sync sa parehong direksyon.
Magsimula nang libre