Kako nastaviti okolje za predprodukcijsko testiranje (staging) za svojo aplikacijo

Za nastavitev staging okolja objavite drugo kopijo aplikacije na njen zasebni URL, ji dodelite lastno podatkovno bazo in testne API ključe ter poskrbite, da se nastavitev čim bolj ujema s produkcijo. Nato vsako pomembnejšo spremembo najprej objavite na staging, prehodite ključne tokove in v produkcijo objavite šele, ko staging deluje pravilno.

Če ta ideja še ni domača, vam kaj je staging okolje pojasni koncept. Ta vodnik je praktična nastavitev za ljudi, ki gradijo z orodji umetne inteligence, ne pa za ekipe DevOps.

Razvoj, staging in produkcija

Večina majhnih aplikacij potrebuje tri okolja, tudi če je prvo samo predogled v vašem orodju za gradnjo:

Namen staginga je, da se obnaša kot produkcija – enaka koda, enak sklad, podobne nastavitve –, toda napaka tam nikomur ne škoduje.

Korak 1: Določite, kaj mora staging ujemati

Staging je uporaben le, če se težave pokažejo tam, preden se pokažejo v produkciji. Uskladite:

• Isto kodo, objavljeno na enak način.
• Isti sklad in različice – ogrodje, izvajalno okolje, vrsto podatkovne baze.
• Isto vrsto nastavitev – enaka imena okoljskih spremenljivk, s testnimi vrednostmi.
• Iste storitve – če ima produkcija spletno aplikacijo in API, ju ima tudi staging.

Lahko se razlikuje po velikosti (manjši stroj je v redu) in po podatkih.

Korak 2: Ustvarite kopijo

Najpreprostejši pristop: druga objava istega projekta na drugem URL-ju, na primer staging.yourapp.com ali yourapp-staging.example.com.

Kako to storite, je odvisno od gostitelja:

• Gostitelji z vgrajenimi predogledi ali staging objavami jih lahko samodejno ustvarijo za vejo v Gitu.
• Gostitelji brez tega: ustvarite drugo aplikacijo ali projekt iz iste kode in ga objavite ločeno.
• Koda v Gitu: ohranjajte vejo staging ali main, ki se objavi na staging, in v produkcijo objavljajte iz izdaje. Glejte kako uporabljati Git z aplikacijo, zgrajeno z umetno inteligenco.

Korak 3: Dajte stagingu lastno podatkovno bazo

Ta korak vas najbolj zaščiti. Če staging in produkcija delita podatkovno bazo, test, ki izbriše zapise, izbriše prave zapise.

• Ustvarite ločeno podatkovno bazo za staging.
• Napolnite jo s semenskimi podatki – realističnimi izmišljenimi zapisi, ki vam jih lahko ustvari umetna inteligenca.
• Če potrebujete kopijo produkcijskih podatkov, najprej odstranite ali zamešajte imena, e-poštne naslove in vse osebne podatke.

Napiši skripto semen, ki napolni prazno podatkovno bazo z realističnimi testnimi podatki: 20 strank, 50 naročil v različnih stanjih in dva skrbniška uporabnika. Uporabi očitno izmišljena imena in e-poštne naslove na example.com.

Preden zaupate nastavitvi, potrdite, na katero podatkovno bazo se vsaka kopija povezuje. Vprašajte neposredno:

Na katero podatkovno bazo se ta aplikacija povezuje in od kod prihaja ta nastavitev? Pokaži mi ime spremenljivke, ne gesla.

Korak 4: Uporabite testne ključe in ločene nastavitve

Vse, kar se povezuje z zunanjo storitvijo, na stagingu naj uporablja testne poverilnice:

• Plačila v testnem načinu (na primer testni ključi Stripe), da se nobena prava kartica ne zaračuna.
• E-pošta poslana v peskovnik ali samo na vaš naslov, da stranke nikoli ne dobijo testnega sporočila.
• Umetna inteligenca in drugi plačljivi API-ji z ločenim ključem in nizko mejo porabe.
• Webhooki, usmerjeni na staging URL, ne na produkcijo.

Imena spremenljivk naj bodo v obeh okoljih enaka, spreminjate samo vrednosti. Tako koda ne potrebuje vedenja, kje se izvaja. Za več o tem glejte kako varno hraniti API ključe.

Korak 5: Naj bo staging zaseben

Staging ne sme biti javen:

• Postavite ga za prijavo, geslo ali seznam dovoljenih e-poštnih naslovov ekipe.
• Preprečite, da bi ga iskalniki indeksirali z oznako noindex ali glavo X-Robots-Tag.
• Nanj ne povezujte z javno spletno stranjo.
• Naj izgleda drugače – barvni pas z napisom »STAGING« prepreči testiranje v napačnem zavihku.

Na vrhu vsake strani dodaj svetlo rumen pas z besedilom »STAGING – samo testni podatki«, kadar je okoljska spremenljivka APP_ENV enaka »staging«. V tem primeru dodaj tudi oznako noindex.

Korak 6: Vzpostavite rutino izdaj

Staging pomaga le, če ga uporabljate vsakič. Preprosta rutina:

1. Naredite spremembo v razvoju in jo preverite v predogledu.
2. Izdajte jo na staging.
3. Prehodite ključne tokove: registracija, prijava, glavna funkcija, plačila, vse, kar se je spremenilo.
4. Če nekaj ne deluje, popravite in znova izdajte na staging.
5. Enako različico objavite v produkcijo.
6. Hitro preverite produkcijo – iste tokove, na kratko.

Ključne tokove zapišite kot kratek testni scenarij. Glejte kako testirati aplikacijo pred lansiranjem, kaj naj vključuje.

Korak 7: Previdno upravljajte spremembe podatkovne baze

Spremembe strukture podatkovne baze – dodajanje stolpca, preimenovanje tabele – so tam, kjer se staging najbolj obrestuje.

• Vsako spremembo strukture najprej zaženite na stagingu.
• Preverite, ali so obstoječi podatki preživeli, ne samo to, ali delujejo nove funkcije.
• Pred izvedbo iste spremembe na produkciji naredite varnostno kopijo produkcije. Glejte kako varnostno kopirati podatkovno bazo aplikacije.
• Raje uporabljajte spremembe, ki dodajajo, ne preimenujejo ali brišejo, da stara različica ostane delujoča, če se vrnete nazaj.

Primeri pozivov

Razloži, kaj bi se zgodilo z obstoječimi podatki, če bi to spremembo podatkovne baze zagnali na produkciji. Se kaj izbriše ali preimenuje?

Naredi, da vse nastavitve, specifične za okolje – URL-je API-ja, ključe, pošiljatelja e-pošte, lasten URL spletnega mesta – prihajajo iz okoljskih spremenljivk z enakimi imeni na stagingu in v produkciji. Naštej jih.

Napiši kratek kontrolni seznam tokov, ki bi jih morala preizkusiti na stagingu pred vsako izdajo, glede na to, kaj ta aplikacija počne.

Pogoste napake

• Skupna podatkovna baza. Najbolj škodljiva napaka. Staging vedno dobi svojo.
• Pravi ključi na stagingu. Pravi zaračuni, pravi e-poštni naslovi pravih strank.
• Staging se oddalji od produkcije. Različne različice ali nastavitve pomenijo, da staging ne lovi več težav.
• Javno, indeksirano staging mesto, ki se prikaže v rezultatih iskanja ob vašem pravem.
• Preskakovanje staginga za »majhne« spremembe. Majhne spremembe tudi razbijejo stvari.
• Testiranje v napačnem zavihku. Vidni pas to popravi.

Kontrolni seznam

• Staging zažene isto kodo, sklad in storitve kot produkcija.
• Staging ima lastno podatkovno bazo s testnimi ali očiščenimi podatki.
• Plačila, e-pošta in plačljivi API-ji na stagingu uporabljajo testne ključe.
• Imena spremenljivk se ujemajo med okolji; razlikujejo se samo vrednosti.
• Staging je za prijavo ali geslom in ni indeksiran.
• Ko ste na stagingu, se prikaže pas.
• Vsaka izdaja gre najprej na staging, s pisnim seznamom tokov za preverjanje.
• Spremembe podatkovne baze se najprej izvedejo na stagingu, z varnostno kopijo produkcije pred izdajo.

Staging na Mythexu

Objava v Mythexu vam da en živ URL na aplikacijo; ločenega preklopa za staging ni. V praksi imate dve možnosti:

• Predogled kot vaša preizkusna točka pred izdajo. Vsak projekt teče v zasebnem oblačnem delovnem prostoru z živim predogledom. /test naj agent klikne skozi predogled kot uporabnik, povezava Deli pa omogoča, da stranka ali sodelavec pregleda predogled, ne da bi ga objavili. Glejte Predogled in koda. Za mnoge samostojne projekte to zadostuje.
• Drugi projekt kot staging. Na načrtu Pro projekt izvozite in ga uvozite v nov projekt, temu projektu dodelite lastno podatkovno bazo in testne skrivnosti ključev ter ga objavite na lastnem slugu. Pred objavo produkcijskega projekta izdajte nanj.

Ne glede na to pred kakršnim koli destruktivnim testiranjem vprašajte agenta, katero podatkovno bazo uporabljata predogled in objavljena aplikacija, in za povrnitev slabe spremembe uporabite kontrolne točke. Za širše uvajanje AI prototipa v produkcijo glejte kako AI prototip prenesti v produkcijo.

Vprašanja