Mag-deploy ng static site sa iyong sariling Azure Static Web Apps account

Ano ang naibibigay sa inyo ng pagkonekta nito

Ang pagkonekta ng inyong sariling Azure Static Web Apps account ay nagbibigay-daan sa inyong mag-publish ng static site sa inyong Azure Static Web Apps account mula sa inyong Zinn® dashboard. Kayo ang may-ari ng proyekto at ng bill; kami ang namamahala sa pag-deploy, sa custom domain at sa mga DNS record.

Bago kayo magsimula

Isang Azure subscription, isang resource group para sa mga site, at isang konektadong GitHub, GitLab o Bitbucket account na naglalaman ng code — nag-build ang Azure Static Web Apps mula sa isang repository. Pinapayagan ng libreng plan ng Azure ang paggamit sa komersyo at dalawang custom domain sa bawat app.

1. Gumawa ng key sa Azure Static Web Apps

Tinatawag ito ng Azure na service principal. Sa Microsoft Entra admin center, buksan ang Entra ID → App registrations → New registration, bigyan ito ng pangalan at i-Register ito. Sa pahina ng overview ng app, kopyahin ang Application (client) ID at ang Directory (tenant) ID. Pagkatapos, buksan ang Certificates & secrets → Client secrets → New client secret, pumili ng tagal at i-Add ito — kopyahin kaagad ang halaga ng secret, minsan lang ito ipinapakita ng Azure.

Sa Azure portal, buksan ang resource group na gusto ninyong gamitin namin, pagkatapos ay Access control (IAM) → Add → Add role assignment. Piliin ang Contributor role, italaga ito sa User, group, or service principal, hanapin ang app sa pamamagitan ng pangalan, at i-Review + assign. Tandaan ang pangalan ng resource group at ang Subscription ID na kinabibilangan nito (hanapin ang Subscriptions sa portal).

2. Konekta ito dito

Buksan ang Integrations sa inyong dashboard at piliin ang Connect an account. Piliin ang Static hosting (Netlify, Vercel) bilang grupo at Azure Static Web Apps bilang account, punan ang Client ID, Client secret, Tenant ID, Subscription ID at Resource group, at pindutin ang Connect account.

Sinusubukan namin ang inyong ipinapaskil bago i-save ang anuman. Ang isang key na hindi gumagana ay hindi kailanman ini-store, at sinasabi ng sagot kung ano ang mali dito. Ang isang key na gumagana ay pinapanatiling naka-encrypt sa aming secrets vault — hindi kailanman sa aming database — at hindi na kailanman ipinapakita muli, kahit sa inyo man.

Ano ang susunod na mangyayari

• Kapag gumawa o naglipat kayo ng static site, lumilitaw ang account na ito bilang deploy target. Nag-build ang Azure Static Web Apps mula sa isang repository — wala itong paraan para tumanggap ng naka-upload na build — kaya ang code ng site ay dapat magmula sa isang konektadong GitHub, GitLab o Bitbucket repository. Kumonekta muna ng isa kung wala pa kayo nito.
• Ginagawa namin ang serbisyo sa iyong account, itinuturo ito sa repository, ikinakabit ang iyong custom domain at nag ti-trigger ng mga deploy. Ipinapakita ng pahina ng domain ang anumang DNS record na kailangan ng Azure Static Web Apps.
• Ang paggamit at pagsingil ay nasa inyong account, na makikita sa inyong sariling dashboard ng vendor.
• Ang isang apex domain ay bina-verify ng isang TXT record at ang isang subdomain sa pamamagitan ng CNAME nito; ipinapakita ng pahina ng domain kung alin ang kailangan ng inyong domain.

Kung hindi ito kumonekta

Tinanggihan ng Azure ang service principal. Alinman sa nag-expire na ang client secret — palagi nilang ginagawa iyon, sa tagal na iyong pinili — o wala nang Contributor ang app sa resource group. Magkamukha ang dalawang mensahe, kaya suriin ang pagtatalaga ng role bago gumawa ng bagong secret.

Walang nakitang anuman. Suriin na ang Subscription ID at Resource group ay ang mga binigyan ninyo ng role, at ang Tenant ID ay ang directory kung saan nakarehistro ang app.

Sinasabi nitong tinanggihan ang key. Halos palaging isa sa tatlong bagay: isang espasyo o isang line break na nakopya kasama nito, isang key na nag-expire na, o isang key na binawi o muling ginawa pagkatapos ninyong kopyahin ito. Gumawa ng bago at i-paskil itong muli.

Kumonekta ito, ngunit may nabigo sa bandang huli. Nag-aauthenticate ang key ngunit kulang sa pahintulot na kailangan ng aksyon. Gumawa ng bagong key na may mga pahintulot na nakalista sa itaas, pagkatapos ay idiskonekta ang lumang koneksyon at ikonekta ang bagong key.

Pagdidiskonekta

Buksan ang Integrations, hanapin ang account at pindutin ang Disconnect. Agad nitong tinatanggal ang naka-store na key. Ang anuman na gumagamit nito ay humihinto sa susunod nitong aksyon, at sinasabi ito ng mga screen na umaasa dito sa halip na mabigo nang tahimik.

Ang pagdidiskonekta ay hindi pinapawalang-bisa ang nagawa na — ang mga record, deployment o setting na binago namin sa inyong account ay nanatili kung ano sila. Kung sa palagay ninyo ay maaaring tumagas ang mismong key, bawiin din ito sa vendor; ang pagdidiskonekta ay nag-aalis ng aming kopya, hindi sa kanila.