Kako podesiti staging okruženje za vašu aplikaciju

Da biste podesili staging okruženje, postavite drugu kopiju aplikacije na sopstveni privatni URL, dajte joj sopstvenu bazu i test API ključeve i neka podešavanje bude što sličnije produkciji. Zatim svaku značajniju izmenu prvo objavite na stagingu, prođite kroz važne tokove i tek kada staging izgleda ispravno, objavite na produkciju.

Ako ste novi u ideji, šta je staging okruženje objašnjava koncept. Ovaj vodič je praktično podešavanje, namenjeno ljudima koji grade uz AI alate, a ne timovima koji vode DevOps.

Dev, staging i produkcija

Većini malih aplikacija trebaju tri mesta, čak i ako je prvo samo pregled vašeg alata za pravljenje:

Smisao stagina je da se ponaša kao produkcija: isti kod, isti stek, ista vrsta podešavanja, ali greška tamo nikoga ne boli.

Korak 1: Odredite šta staging mora da odgovara

Staging je koristan samo ako se problemi pojave tamo pre nego u produkciji. Uskladite:

• Isti kod, objavljen na isti način.
• Isti stek i verzije: framework, runtime, tip baze.
• Istu vrstu konfiguracije: ista imena environment varijabli, sa test vrednostima.
• Iste servise: ako produkcija ima web aplikaciju i API, staging ima oba.

Može se razlikovati po veličini (manja mašina je u redu) i po podacima.

Korak 2: Napravite kopiju

Najjednostavniji pristup je drugi deployment istog projekta, na drugom URL-u, na primer staging.yourapp.com ili yourapp-staging.example.com.

Kako to uraditi zavisi od vašeg hosta:

• Hostovi sa ugrađenim preview ili staging deployment-ima mogu automatski da naprave jedan za granu u Git-u.
• Hostovi bez toga: napravite drugu aplikaciju ili projekat od istog koda i deploy-ujte ga odvojeno.
• Kod u Git-u: držite granu staging ili main koja se deploy-uje na staging, a na produkciju deploy-ujte iz izdanja. Pogledajte kako koristiti Git sa aplikacijom generisanom AI-jem.

Korak 3: Dajte stagingu sopstvenu bazu

Ovaj korak vas štiti. Ako staging i produkcija dele bazu, test koji briše zapise briše prave zapise.

• Napravite posebnu bazu za staging.
• Napunite je seed podacima, realističnim lažnim zapisima koje AI može da generiše za vas.
• Ako su vam potrebni podaci iz produkcije, pre toga uklonite ili izmešajte imena, emailove i sve lično.

Napiši seed skriptu koja puni praznu bazu realističnim test podacima: 20 kupaca, 50 porudžbina u različitim stanjima i dva admin korisnika. Koristi očigledno lažna imena i email adrese na example.com.

Pre nego što verujete podešavanju, potvrdite na koju bazu se svaka kopija povezuje. Pitajte direktno:

Na koju bazu se ova aplikacija povezuje i odakle dolazi to podešavanje? Pokaži mi ime varijable, a ne lozinku.

Korak 4: Koristite test ključeve i odvojena podešavanja

Sve što komunicira sa spoljnim servisom treba da koristi test kredencijale na stagingu:

• Plaćanja u test režimu (na primer Stripe test ključevi), da se nijedna prava kartica ne tereti.
• Email šalje se na sandbox ili samo na vašu adresu, da kupci nikada ne dobiju test poruku.
• AI i drugi plaćeni API-ji sa posebnim ključem i niskim limitom potrošnje.
• Webhook-ovi usmereni na staging URL, a ne na produkciju.

Držite imena varijabli ista u oba okruženja i menjajte samo vrednosti. Tako kod ne mora da zna gde se izvršava. Za više o tome pogledajte kako čuvati API ključeve bezbednim.

Korak 5: Držite staging privatnim

Staging ne bi trebalo da bude javan:

• Stavite ga iza prijave, lozinke ili liste dozvoljenih timskih emailova.
• Sprečite indeksiranje u pretraživačima pomoću noindex meta taga ili X-Robots-Tag zaglavlja.
• Ne linkujte ga sa javnog sajta.
• Neka izgleda drugačije: obojen baner „STAGING“ sprečava testiranje u pogrešnom tabu.

Dodaj jasno žuti baner na vrhu svake stranice sa tekstom „STAGING — samo test podaci“ kada je environment varijabla APP_ENV jednaka „staging“. U tom slučaju dodaj i noindex meta tag.

Korak 6: Uspostavite rutinu izdavanja

Staging pomaže samo ako ga koristite svaki put. Jednostavna rutina:

1. Napravite izmenu u development okruženju i proverite je u preview-u.
2. Objavite je na staging.
3. Prođite kroz ključne tokove: registracija, prijava, glavna funkcija, plaćanja i sve što je izmena dotakla.
4. Ako nešto pukne, popravite i ponovo objavite na staging.
5. Objavite istu verziju na produkciju.
6. Brzo proverite produkciju: iste tokove, ukratko.

Ključne tokove zapišite kao kratku test skriptu. Pogledajte kako testirati aplikaciju pre lansiranja za to šta da uključite.

Korak 7: Pažljivo menjajte bazu

Izmene strukture baze, na primer dodavanje kolone ili preimenovanje tabele, su mesto gde staging pokazuje vrednost.

• Svaku strukturnu izmenu prvo pokrenite na stagingu.
• Proverite da su postojeći podaci preživeli, a ne samo da novi funkcioniši.
• Napravite rezervnu kopiju produkcije pre nego što istu izmenu pokrenete tamo. Pogledajte kako napraviti rezervnu kopiju baze aplikacije.
• Birajte izmene koje dodaju umesto da preimenuju ili brišu, da bi stara verzija i dalje radila ako se vratite unazad.

Primeri promptova

Objasni šta bi se desilo sa postojećim podacima ako ovu izmenu baze pokrenemo na produkciji. Da li se nešto briše ili preimenuje?

Neka sva podešavanja specifična za okruženje, API URL-ovi, ključevi, pošiljalac emaila i sopstveni URL sajta, dolaze iz environment varijabli sa istim imenima na stagingu i produkciji. Navedi ih.

Napiši kratku checklistu tokova koje treba da testiram na stagingu pre svakog izdanja, na osnovu onoga što ova aplikacija radi.

Uobičajene greške

• Deljena baza. Najštetnija greška. Staging uvek dobija sopstvenu.
• Živi ključevi na stagingu. Prava naplata, pravi emailovi pravim kupcima.
• Staging se udaljava od produkcije. Različite verzije ili podešavanja znače da staging prestaje da hvata probleme.
• Javan, indeksiran staging sajt koji se pojavi u rezultatima pretrage pored pravog.
• Preskakanje stagina za „male“ izmene. I male izmene nekada lome stvari.
• Testiranje u pogrešnom tabu. Vidljiv baner to rešava.

Checklista

• Staging pokreće isti kod, stek i servise kao produkcija.
• Staging ima sopstvenu bazu sa test ili očišćenim podacima.
• Plaćanja, email i plaćeni API-ji koriste test ključeve na stagingu.
• Imena varijabli se poklapaju među okruženjima; menjaju se samo vrednosti.
• Staging je iza prijave ili lozinke i nije indeksiran.
• Baner se prikazuje kada ste na stagingu.
• Svako izdanje ide prvo na staging, sa napisanom listom tokova za proveru.
• Izmene baze se prvo pokreću na stagingu, uz rezervnu kopiju produkcije pre objave.

Staging na Mythex-u

Mythex-ov Publish daje jedan živi URL po aplikaciji; ne postoji zasebni staging prekidač. U praksi imate dve opcije:

• Preview kao pre-release provera. Svaki projekat radi u privatnom cloud radnom prostoru sa živim Preview-om. /test pušta agenta da klikće kroz njega kao korisnik, a Share link omogućava klijentu ili kolegi da pregleda preview bez objavljivanja. Pogledajte Preview i Code. Ovo je dovoljno za mnoge solo projekte.
• Drugi projekat kao staging. Na Pro planu izvezite projekat i uvezite ga u novi projekat, dajte mu sopstvenu bazu i test ključeve kao tajne, pa ga objavite na sopstvenom slug-u. Objavljujte na njemu pre nego što objavite produkcioni projekat.

U oba slučaja pitajte agenta na koju bazu se povezuju preview i objavljena aplikacija pre nego što testirate bilo šta destruktivno, a za vraćanje lošeg izmena koristite checkpoint-e. Za širi pregled kako aplikaciju pustiti u rad pogledajte kako prebaciti AI prototip u produkciju.

Pitanja