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

Kapag gumagana na nang lokal ang isang proyekto, apat na command ang nagdadala nito sa isang live na site sa Zinn Digital® hosting: mag-sign in, i-link ang proyekto sa isang hosting slot, basahin ang pre-flight, at i-push. Tinatalakay ng artikulong ito ang bawat isa, kung ano ang ipinapakita nito, at ang mga command na ginagamit pagkatapos — mga muling pag-deploy, kasaysayan ng pag-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 ay:

zinnector login

Ang key ay tina-type sa isang prompt — kailanman ay hindi ito tinatanggap sa command line, kaya hindi ito mapupunta sa iyong shell history o 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. Ang key ay bina-verify bago ito i-store, at iniimbak ito gamit ang file mode 600. Ipinapakita ng zinnector whoami --scopes kung aling organisasyon ang iyong pinag-sign-in-an at kung aling mga pahintulot ang taglay ng key; ang isang sandbox key ay may tatak bilang ganoon.

I-link ang proyekto sa isang slot

zinnector link                                   # mamili 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 na lamang kung ipapasa mo ang --no-repo, kinokonekta nito ang git remote ng proyekto sa site sa platform upang mai-deploy ito sa pamamagitan ng pag-push. I-commit ang zinnector.json: ang isang kasamahan na nag-clone ng repository ay makakapag-deploy sa parehong lugar nang hindi na kailangang sabihan. Wala itong dalang 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 ilalagay at ipinapakita ang bawat hindi pagtutugma — at bawat paghahambing na hindi nito nagawa:

• Bersyon ng PHP, na may agwat sa pangunahing bersyon (major-version gap) na minarkahang mataas dahil tiyak na sinisira nito ang isang site at ang mas mababang agwat ay mas mababa ang marka, dahil ang pagbibigay ng marka sa lahat bilang kritikal ay nagtuturo sa mga tao na laktawan ang babala.
• Kung ang slot ay maaaring lumipat sa bersyon na iyong binuo, kung ang PHP ng slot ay lampas na sa katapusan ng buhay nito (end of life), at kung ang makina ay nag-apply na ng bersyon o sinabihan lamang.
• Ang laki at bilang ng file ng iyong proyekto kumpara sa disk at inode headroom na talagang natitira sa slot — ang isang punong WordPress ay maaaring maubusan ng mga file habang nasa ilalim pa rin ng limitasyon ng disk nito.
• Ang mga bersyon ng WordPress sa bawat panig, kung natapos na sa pag-provision ang slot, at kung ang isang repository ay nakakonekta upang pag-pushan.

Nagbibigay ito ng babala; hindi ito kailanman humaharang. Ang bawat natuklasan ay maaaring i-override gamit ang zinnector push --force, dahil alam mo ang mga bagay tungkol sa iyong sariling site na hindi alam ng isang checker. Ang isang paghahambing na hindi nagawa ay naiuulat bilang unknown, hinding-hindi bilang tagumpay, at palaging sinasabi ng buod kung ilan ang mga ito. Bilang default, ang lokal na bersyon ng PHP ay ang ipinahayag sa zinnector.json; ang --probe ay nag-a-activate sa lokal na runtime at sinusukat ito sa halip. Ang --strict ay nag-e-exit na hindi zero sa mga unknown din, na siyang gusto ng isang CI gate.

I-push

zinnector push

Pinapatakbo ng push ang pre-flight, pinupush ang iyong mga commit, pinu-trigger ang pag-deploy at binabantayan ito hanggang sa matapos, ipinapakita ang huling katayuan at ang nai-deploy na commit. Ginagawa ng --dry-run ang lahat maliban sa pag-deploy; pinu-trigger ito ng --no-wait at nag-e-exit; idine-deploy ng --no-git kung anoman ang mayroon na sa platform nang walang pag-push. Kung ang nai-deploy na commit ay hindi ang kakatapos pa lang i-push, sinasabi nito iyon.

Kapag may naganap na mali

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

Tumatakbo ang zinnector ai sa platform laban sa iyong sariling account, kaya nakikita nito ang parehong kasaysayan ng pag-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 hinding-hindi ang mga nilalaman ng file.

Kaugnay

• Pagsisimula · Lokal na pag-unlad · Sanggunian ng command · Pag-troubleshoot