Pag-deploy gamit ang Zinnector®: i-link, suriin, i-push

Kapag gumagana na ang isang proyekto sa lokal na kapaligiran, apat na command ang magdadala rito sa isang live site sa Zinn Digital® hosting: mag-sign in, i-link ang proyekto sa isang hosting slot, basahin ang pre-flight, at mag-push. Ipinapaliwanag ng artikulong ito ang bawat isa, kung ano ang ipinapakita nito, at ang mga command na gagamitin mo pagkatapos — mga redeploy, history ng deploy, at mga log ng build.

Mag-sign in gamit ang isang API key

Gumawa ng key sa dashboard sa ilalim ng Settings → API keys, pagkatapos:

zinnector login

Itina-type ang key sa isang prompt — kailanman ay hindi ito tinatanggap sa command line, kaya hindi ito mapupunta sa history ng iyong shell o sa listahan ng proseso. Sa CI, i-pipe ito: echo "$ZINN_API_KEY" | zinnector login --profile ci, o itakda ang ZINNECTOR_TOKEN at laktawan nang buo ang login. Bineberipika ang key bago ito iimbak, at iniimbak ito gamit ang file mode 600. Ipinapakita ng zinnector whoami --scopes kung saang organisasyon ka naka-sign in at kung anong mga pahintulot ang taglay ng key; ang isang sandbox key ay may label bilang ganoon.

I-link ang proyekto sa isang slot

zinnector link                                   # pumili ng site mula sa isang listahan
zinnector link example.com --repo acme/site --branch main

Isinusulat ng link ang id ng site sa zinnector.json at, maliban kung ipapasa mo ang --no-repo, ikinokonekta nito ang git remote ng proyekto sa site sa platform upang mai-deploy ito kapag nag-push. I-commit ang zinnector.json: ang isang kasamahang mag-clone ng repository ay magde-deploy sa parehong lugar nang hindi na kailangang sabihan pa. Wala itong hawak na lihim.

Basahin ang pre-flight

zinnector check

Ito ang command kung bakit umiiral ang CLI. Inihahambing nito ang iyong proyekto sa slot kung saan ito nakatakdang i-deploy at ipinapakita ang bawat hindi tugma — at bawat paghahambing na hindi nito nagawa:

• Bersyon ng PHP, na may agwat sa pangunahing bersyon (major-version) na may gradong high dahil tiyak nitong sinisira ang isang site, at isang mas maliit na agwat (minor gap) na may mas mababang grado, dahil ang pagmamarka sa lahat bilang kritikal ay nagtuturo sa mga taong laktawan ang babala.
• Kung ang slot ay maaaring lumipat sa bersyong ginamit mo sa pag-build, kung ang PHP ng slot ay lampas na sa end of life, at kung nailapat na ng makina ang bersyon o nasabihan lamang ito.
• Ang laki at bilang ng file ng iyong proyekto kumpara sa natitirang espasyo sa disk at inode na aktwal na natitira sa slot — ang isang WordPress tree ay maaaring maubusan ng mga file habang malayo pa sa limitasyon ng disk nito.
• Ang mga bersyon ng WordPress sa bawat panig, kung natapos na ng slot ang pag-provision, at kung may nakakonektang repository na mapagpu-push-an.

Nagbababala ito; hindi ito kailanman humaharang. Ang bawat natuklasan ay maaaring i-override gamit ang zinnector push --force, dahil may mga alam ka tungkol sa sarili mong site na hindi alam ng isang checker. Ang isang paghahambing na hindi nagawa ay iuulat bilang unknown, hindi kailanman bilang pumasa (pass), at palaging sinasabi ng buod kung ilan ang mga ito. Bilang default, ang lokal na bersyon ng PHP ay ang siyang idineklara sa zinnector.json; ibinuboot ng --probe ang lokal na runtime at sinusukat ito sa halip. Ang --strict ay lumalabas na may non-zero code kahit sa mga unknown, na siyang kailangan ng isang CI gate.

Mag-push

zinnector push

Pinapatakbo ng push ang pre-flight, ipinupush ang iyong mga commit, pinasimulan ang pag-deploy at binabantayan ito hanggang sa matapos, habang ipinapakita ang pinal na katayuan at ang na-deploy na commit. Ginagawa ng --dry-run ang lahat maliban sa pag-deploy; pinasimulan ito ng --no-wait at lumalabas agad; dine-deploy naman ng --no-git ang anumang mayroon na sa platform nang hindi nagpu-push. Kung ang na-deploy na commit ay hindi ang kalalabas lamang na na-push, sasabihin nito iyon.

Kapag may nagkaproblema

zinnector deploys example.com        # history ng deploy — katayuan, commit, trigger, mensahe
zinnector logs example.com --build   # ang build log ng pinakabagong pag-deploy
zinnector logs example.com --error   # ang log ng error ng site
zinnector deploy example.com         # i-deploy muli ang mayroon na sa platform
zinnector ai "bakit bumabagsak ang aking pag-deploy?"

Tumatakbo ang zinnector ai sa platform gamit ang iyong sariling account, kaya nakikita nito ang parehong history ng deploy at mga log. Mula sa loob ng isang proyekto, ipinapadala nito ang hugis ng proyekto — mga pangalan ng directory, mga bersyon, at ang id ng site — at kailanman ay hindi ang mga nilalaman ng file.

Kaugnay

• Pagsisimula · Lokal na pag-develop · Sanggunian ng command · Pagtugon sa mga problema