Paano Mag-set Up ng Staging Environment para sa App Mo

Para mag-set up ng staging environment, i-deploy ang pangalawang kopya ng app mo sa sarili nitong pribadong URL, bigyan ito ng sariling database at test API key, at gawin itong kasing-tugma ng production hangga't maaari. Pagkatapos, i-release muna sa staging ang bawat mahalagang pagbabago, dumaan sa mga pangunahing flow, at saka lamang mag-publish sa production kapag maayos ang lahat sa staging.

Kung bago ka pa sa ideya, ipinapaliwanag ng ano ang staging environment ang konsepto. Ang gabay na ito ay ang praktikal na setup, para sa mga taong gumagawa gamit ang AI tool at hindi nagpapatakbo ng DevOps team.

Dev, staging at production

Karamihan ng maliliit na app ay nangangailangan ng tatlong lugar, kahit ang una ay preview lang ng builder mo:

Ang punto ng staging ay kumilos ito tulad ng production: parehong code, parehong stack, parehong uri ng setting, pero walang masasaktan kapag may nagkamali dito.

Hakbang 1: Alamin kung ano ang dapat tumugma sa staging

Makakatulong lamang ang staging kung may mga problemang lumalabas doon bago pa sa production. Dapat magtugma ang:

• Ang parehong code, na nire-release sa parehong paraan.
• Ang parehong stack at bersyon: framework, runtime, uri ng database.
• Ang parehong uri ng configuration: parehong pangalan ng environment variable, na may test na halaga.
• Ang parehong serbisyo: kung may web app at API ang production, ganoon din ang staging.

Puwedeng magkaiba ang laki (ayos lang ang mas maliit na makina) at ang data.

Hakbang 2: Gawin ang kopya

Ang pinakasimpleng paraan: pangalawang deployment ng parehong proyekto, sa ibang URL gaya ng staging.yourapp.com o yourapp-staging.example.com.

Depende sa host mo kung paano ito gagawin:

• Mga host na may built-in na preview o staging deployment ay maaaring gumawa nito nang awtomatiko para sa isang Git branch.
• Mga host na wala nito: gumawa ng pangalawang app o proyekto mula sa parehong code, at i-deploy ito nang hiwalay.
• Code sa Git: magpanatili ng staging o main branch na nagde-deploy sa staging, at mag-deploy sa production mula sa release. Tingnan ang paano gamitin ang Git sa AI-built na app.

Hakbang 3: Bigyan ang staging ng sariling database

Ito ang hakbang na nagpoprotekta sa iyo. Kapag nagbahagi ng database ang staging at production, ang test na nagbubura ng record ay magbubura ng totoong record.

• Gumawa ng hiwalay na database para sa staging.
• Punuin ito ng seed data: makatotohanang pekeng record na maaaring gawin ng AI para sa iyo.
• Kung kailangan mo ng kopya ng production data, alisin o i-scramble muna ang mga pangalan, email at anumang personal na impormasyon.

Sumulat ng seed script na pupuno sa walang laman na database ng makatotohanang test data: 20 customer, 50 order sa iba't ibang estado, at dalawang admin user. Gumamit ng halatang pekeng pangalan at example.com na email address.

Bago ka magtiwala sa setup, kumpirmahin kung aling database ang kinokonekta ng bawat kopya. Itanong nang diretso:

Aling database ang kinokonektahan ng app na ito, at saan galing ang setting na iyon? Ipakita ang pangalan ng variable, hindi ang password.

Hakbang 4: Gumamit ng test key at hiwalay na setting

Lahat ng nakikipag-usap sa labas na serbisyo ay dapat gumamit ng test na credential sa staging:

• Bayad sa test mode (halimbawa, Stripe test keys), para walang totoong card na sisingilin.
• Email na ipinapadala sa sandbox o sa sarili mong address lamang, para walang makatanggap ng test message na customer.
• AI at iba pang bayad na API na may hiwalay na key at mababang spending cap.
• Webhook na nakaturo sa staging URL, hindi sa production.

Panatilihing pareho ang mga pangalan ng variable sa dalawang environment at ang mga halaga lang ang nagkakaiba. Sa ganoon, hindi kailangang malaman ng code kung saan ito tumatakbo. Para pa sa higit na detalye, tingnan ang paano panatilihing ligtas ang API key.

Hakbang 5: Panatilihing pribado ang staging

Hindi dapat public ang staging:

• Ilagay ito sa likod ng login, password, o listahan ng pinapayagang team email.
• Pigilan ang pag-index ng search engine sa pamamagitan ng noindex meta tag o X-Robots-Tag header.
• Huwag itong i-link mula sa public site mo.
• Gawin itong iba ang itsura: ang banner na may kulay na "STAGING" ay pumipigil sa pagsubok sa maling tab.

Magdagdag ng matingkad na dilaw na banner sa itaas ng bawat page na nagsasabing "STAGING — test data lamang" kapag ang APP_ENV environment variable ay "staging". Magdagdag din ng noindex meta tag sa kasong iyon.

Hakbang 6: Gumawa ng release routine

Makakatulong lamang ang staging kung palagi mo itong ginagamit. Simpleng routine:

1. Gawin ang pagbabago sa development at suriin ito sa preview.
2. I-release sa staging.
3. Dumaan sa mga pangunahing flow: mag-sign up, mag-log in, ang pangunahing feature, bayad, at anumang hinawakan ng pagbabago.
4. Kung may masira, ayusin at i-release ulit sa staging.
5. I-publish ang parehong bersyon sa production.
6. Mabilisang suriin ang production: parehong flow, sandali lang.

Isulat ang mga pangunahing flow bilang maikling test script. Tingnan ang paano subukan ang app mo bago ilunsad para sa dapat isama.

Hakbang 7: Maingat na hawakan ang mga pagbabago sa database

Ang mga pagbabago sa istruktura ng database, gaya ng pagdagdag ng column o pagpapalit ng pangalan ng table, ay kung saan napatutunayan ang halaga ng staging.

• Patakbuhin muna sa staging ang bawat pagbabago sa istruktura.
• Suriin na nanatiling buo ang umiiral na data, hindi lang kung gumagana ang mga bagong feature.
• Kumuha ng backup ng production bago patakbuhin ang parehong pagbabago doon. Tingnan ang paano i-back up ang database ng app mo.
• Mas piliin ang mga pagbabagong nagdadagdag kaysa nagpapalit ng pangalan o nagbubura, para gumana pa rin ang lumang bersyon kapag nag-rollback ka.

Mga halimbawang prompt

Ipaliwanag kung ano ang mangyayari sa umiiral na data kung patakbuhin ang pagbabago sa database na ito sa production. May nabubura ba o napapalitan ng pangalan?

Gawing galing sa environment variables ang lahat ng setting na tiyak sa environment, gaya ng API URL, key, email sender, at sariling URL ng site; ang mga pangalan ay dapat pareho sa staging at production. Ilista ang mga ito.

Sumulat ng maikling checklist ng mga flow na dapat kong subukan sa staging bago ang bawat release, batay sa ginagawa ng app na ito.

Mga karaniwang pagkakamali

• Shared na database. Ang pinakamapanirang pagkakamali. Laging may sariling database ang staging.
• Live key sa staging. Totoong singil, totoong email sa totoong customer.
• Lumalayo ang staging sa production. Ang magkaibang bersyon o setting ay nangangahulugang hindi na nahuhuli ng staging ang mga problema.
• Public at naii-index na staging site na lumalabas sa search result sa tabi ng totoong site mo.
• Paglaktaw sa staging para sa "maliliit" na pagbabago. Nasisira rin ng maliliit na pagbabago ang mga bagay.
• Pagsubok sa maling tab. Inaayos ito ng nakikitang banner.

Checklist

• Pareho ang code, stack at serbisyo ng staging at production.
• May sariling database ang staging na may test o nilinis na data.
• Test key ang gamit ng bayad, email at bayad na API sa staging.
• Magkapareho ang pangalan ng variable sa bawat environment; halaga lang ang nagkakaiba.
• Nasa likod ng login o password ang staging at hindi ito naii-index.
• May banner na lumalabas kapag nasa staging ka.
• Bawat release ay dumadaan muna sa staging, may nakasulat na listahan ng flow na susuriin.
• Ang mga pagbabago sa database ay unang pinapatakbo sa staging, may backup ng production bago i-release.

Staging sa Mythex

Ang Publish ng Mythex ay nagbibigay ng isang live na URL kada app; walang hiwalay na staging toggle. Sa praktika, dalawa ang opsyon mo:

• Preview bilang pre-release check. Ang bawat proyekto ay tumatakbo sa pribadong cloud workspace na may live na Preview. Ang /test ay nagpapa-click ng agent sa preview na parang user, at ang Share link ay nagbibigay-daan sa kliyente o kasamahan na suriin ang preview nang hindi nagpa-publish. Tingnan ang Preview and Code. Sapat na ito para sa maraming solo na proyekto.
• Pangalawang proyekto bilang staging. Sa Pro, i-export ang proyekto at i-import sa bagong proyekto, bigyan ito ng sariling database at test-key secrets, at i-publish sa sarili nitong slug. I-release dito bago mo i-publish ang production na proyekto.

Alinman ang piliin, itanong sa agent kung aling database ang ginagamit ng preview at ng published na app bago sumubok ng anumang nakakasira, at gumamit ng checkpoint para mag-rollback ng masamang pagbabago. Para sa mas malawak na paraan ng pagpapalabas ng app, tingnan ang paano dalhin sa production ang AI prototype.

Mga tanong