Si të konfiguroni një mjedis staging për aplikacionin tuaj

Për të konfiguruar një mjedis staging, vendosni një kopje të dytë të aplikacionit tuaj në URL-në e vet private, jepini bazën e vet të të dhënave dhe çelësat API test, dhe bëjeni të përputhet me konfigurimin e prodhimit sa më shumë që të jetë e mundur. Pastaj publikoni çdo ndryshim të rëndësishëm fillimisht në staging, kaloni në rrjedhat kryesore dhe publikoni në prodhim vetëm kur staging duket i saktë.

Nëse e keni të re idenë, çfarë është një mjedis staging shpjegon konceptin. Ky udhëzues është konfigurimi praktik, i shkruar për njerëzit që ndërtojnë me mjete AI, jo për ekipe DevOps.

Zhvillim, staging dhe prodhim

Shumica e aplikacioneve të vogla kanë nevojë për tre vende, edhe nëse i pari është thjesht parapamja e ndërtuesit tuaj:

Qëllimi i stagingut është që të sillet si prodhimi — i njëjti kod, i njëjti stack, i njëjti lloj cilësimesh — por një gabim atje nuk dëmton askënd.

Hapi 1: Vendosni çfarë duhet të përputhet staging

Staging është i dobishëm vetëm nëse problemet dalin atje para se të dalin në prodhim. Përputhni:

• Kodin e njëjtë, të publikuar në të njëjtën mënyrë.
• Të njëjtin stack dhe versione — framework, runtime, lloji i bazës së të dhënave.
• Të njëjtin lloj konfigurimi — të njëjtat emra variablash mjedisi, me vlera test.
• Të njëjtat shërbime — nëse prodhimi ka një aplikacion web dhe një API, staging ka të dyja.

Mund të ndryshojë në madhësi (një makinë më e vogël është në rregull) dhe në të dhëna.

Hapi 2: Krijoni kopjen

Mënyra më e thjeshtë: një vendosje e dytë e të njëjtit projekt, në një URL tjetër si staging.yourapp.com ose yourapp-staging.example.com.

Si e bëni këtë varet nga hosti juaj:

• Hostet me vendosje parapamjeje ose stagingu të integruara mund të krijojnë një automatikisht për një degë Git.
• Hostet pa këtë: krijoni një aplikacion ose projekt të dytë nga i njëjti kod, dhe vendoseni veças.
• Kodi në Git: mbani një degë staging ose main që vendoset në staging, dhe vendosni në prodhim nga një publikim. Shihni si të përdorni Git me një aplikacion të ndërtuar me AI.

Hapi 3: Jepini stagingut bazën e vet të të dhënave

Ky është hapi që ju mbron. Nëse staging dhe prodhimi ndajnë një bazë të dhënash, një test që fshin regjistrime fshin regjistrime të vërteta.

• Krijoni një bazë të dhënash të veçantë për staging.
• Mbusheni me të dhëna fillestare — regjistrime realiste të rreme që AI mund t'i gjenerojë për ju.
• Nëse ju duhet një kopje e të dhënave të prodhimit, hiqni ose përzieni fillimisht emrat, email-et dhe çdo gjë personale.

Shkruaj një skript fillestar që mbush një bazë të dhënash bosh me të dhëna test realiste: 20 klientë, 50 porosi në gjendje të ndryshme, dhe dy përdorues administratorë. Përdor emra qartësisht të rremë dhe adresa email example.com.

Para se t'i besoni konfigurimit, konfirmoni cilës bazë të dhënash i lidhet secila kopje. Pyeteni drejtpërdrejt:

Me cilën bazë të dhënash lidhet kjo aplikacion, dhe nga vjen ky cilësim? Më trego emrin e variablës, jo fjalëkalimin.

Hapi 4: Përdorni çelësa test dhe cilësime të veçanta

Çdo gjë që komunikon me një shërbim të jashtëm duhet të përdorë kredenciale test në staging:

• Pagesat në modalitet test (për shembull çelësat test të Stripe), që asnjë kartë e vërtetë të mos ngarkohet.
• Email-i i dërguar te një sandbox ose vetëm te adresa juaj, që klientët të mos marrin kurrë një mesazh test.
• AI dhe API të tjera me pagesë me një çelës të veçantë dhe një kufi të ulët shpenzimi.
• Webhook-et të drejtuara te URL-ja e stagingut, jo te prodhimi.

Mbajini emrat e variablave të njëjtë në të dyja mjediset dhe ndryshoni vetëm vlerat. Kështu kodi nuk ka nevojë të dijë ku po ekzekutohet. Për më shumë, shihni si të mbani çelësat API të sigurt.

Hapi 5: Mbajeni stagingun privat

Staging nuk duhet të jetë publik:

• Vendoseni pas një hyrjeje, një fjalëkalimi, ose një liste të lejuar me email-e ekipi.
• Ndaloni motorët e kërkimit ta indeksojnë me një etiketë meta noindex ose header X-Robots-Tag.
• Mos lidhni me të nga faqja juaj publike.
• Bëjeni të dukshëm të ndryshëm — një banner me ngjyrë "STAGING" parandalon testimin në skedën e gabuar.

Shto një banner të verdhë të ndritshëm në krye të çdo faqeje që thotë "STAGING — vetëm të dhëna test" kur variabla e mjedisit APP_ENV është "staging". Shto gjithashtu një etiketë meta noindex në atë rast.

Hapi 6: Krijoni një rutinë publikimi

Staging ndihmon vetëm nëse e përdorni çdo herë. Një rutinë e thjeshtë:

1. Bëni ndryshimin në zhvillim dhe kontrolloni te parapamja.
2. Publikojeni në staging.
3. Kaloni rrjedhat kryesore: regjistrimi, hyrja, veçoria kryesore, pagesat, çdo gjë që preku ndryshimi.
4. Nëse diçka prishet, rregullojeni dhe publikojeni përsëri në staging.
5. Publikoni të njëjtën version në prodhim.
6. Kontrolloni shpejt prodhimin — të njëjtat rrjedha, shkurt.

Shkruani rrjedhat kryesore si një skript të shkurtër testimi. Shihni si të testoni aplikacionin tuaj para lansimit për atë që duhet të përfshihet.

Hapi 7: Trajtoni me kujdes ndryshimet e bazës së të dhënave

Ndryshimet në strukturën e bazës së të dhënave — shtimi i një kolone, riemërtimi i një tabele — janë vendi ku staging fiton vlerën e vet.

• Ekzekutoni çdo ndryshim strukturor fillimisht në staging.
• Kontrolloni që të dhënat ekzistuese mbijetuan, jo vetëm që veçoritë e reja funksionojnë.
• Bëni një kopje rezervë të prodhimit para se të ekzekutoni të njëjtin ndryshim atje. Shihni si të bëni kopje rezervë të bazës së të dhënave të aplikacionit.
• Preferoni ndryshime që shtojnë në vend që të riemërtojnë ose fshijnë, që versioni i vjetër të funksionojë akoma nëse kthehiet pas.

Shembuj kërkesash

Shpjego çfarë do t'i ndodhte të dhënave ekzistuese nëse do të ekzekutonim këtë ndryshim të bazës së të dhënave në prodhim. A fshihet apo riemërtohet diçka?

Bëj që të gjitha cilësimet specifike të mjedisit — URL-të e API-t, çelësat, dërguesi i email-it, URL-ja e vetë faqes — të vijnë nga variablat e mjedisit me të njëjtat emra në staging dhe në prodhim. Listoji ato.

Shkruaj një listë të shkurtër kontrolli me rrjedhat që duhet të testoj në staging para çdo publikimi, bazuar në atë që bën ky aplikacion.

Gabimet e zakonshme

• Bazë e përbashkët të dhënash. Gabimi më i dëmshëm. Staging merr gjithmonë bazën e vet.
• Çelësa live në staging. Ngarkesa reale, email-e reale te klientë të vërtetë.
• Staging largohet nga prodhimi. Versione ose cilësime të ndryshme do të thotë se staging ndalon së zbuluari problemet.
• Një faqe staging publike dhe e indeksuar që del në rezultatet e kërkimit pranë faqes suaj reale.
• Kapërcimi i stagingut për ndryshime "të vogla". Edhe ndryshimet e vogla prishin gjëra.
• Testimi në skedën e gabuar. Një banner i dukshëm e zgjidh këtë.

Lista kontrolli

• Staging ekzekuton të njëjtin kod, stack dhe shërbime si prodhimi.
• Staging ka bazën e vet të të dhënave me të dhëna test ose të pastruara.
• Pagesat, email-i dhe API-t me pagesë përdorin çelësa test në staging.
• Emrat e variablave përputhen midis mjediseve; ndryshojnë vetëm vlerat.
• Staging është pas hyrjes ose fjalëkalimit dhe nuk indeksohet.
• Shfaqet një banner kur jeni në staging.
• Çdo publikim shkon fillimisht në staging, me një listë të shkruar të rrjedhave për t'u kontrolluar.
• Ndryshimet e bazës së të dhënave ekzekutohen fillimisht në staging, me kopje rezervë të prodhimit përpara publikimit.

Staging në Mythex

Publikimi i Mythex ju jep një URL të vetme live për çdo aplikacion; nuk ka një çelës të veçantë staging. Në praktikë keni dy mundësi:

• Parapamja si kontroll para publikimit. Çdo projekt ekzekutohet në një hapësirë pune private në cloud me një Parapamje live. /test e ka agjentin të klikojë nëpër të si një përdorues, dhe një lidhje Share lejon një klient ose anëtar ekipi ta shqyrtojë parapamjen pa e publikuar. Shihni Parapamja dhe Kodi. Kjo mjafton për shumë projekte individuale.
• Një projekt i dytë si staging. Në Pro, eksportoni projektin dhe importojeni në një projekt të ri, jepini atij projektit bazën e vet të të dhënave dhe sekretet me çelësa test, dhe publikojeni me slug-un e vet. Publikoni te ai përpara se të publikoni projektin e prodhimit.

Në të dyja rastet, pyeteni agjentin cilën bazë të dhënave përdorin parapamja dhe aplikacioni i publikuar përpara se të testoni diçka destruktive, dhe përdorni pikat e kontrollit për t'u kthyer pas një ndryshimi të keq. Për të çuar një aplikacion live në përgjithësi, shihni si të çoni një prototip AI në prodhim.

Pyetje