Kako postaviti staging okruženje za vašu aplikaciju

Da biste postavili staging okruženje, deploy-ujte drugu kopiju aplikacije na njen privatni URL, dajte joj vlastitu bazu podataka i test API ključeve i učinite da što je moguće više odgovara postavkama produkcije. Zatim svaku značajniju promjenu prvo objavite na stagingu, prođite kroz važne tokove i tek kada staging izgleda ispravno objavite na produkciju.

Ako ste novi u ovoj ideji, šta je staging okruženje objašnjava koncept. Ovaj vodič je praktično postavljanje, napisano za ljude koji grade uz AI alate, a ne za tim za DevOps.

Dev, staging i produkcija

Većini malih aplikacija trebaju tri mjesta, čak i ako je prvo samo pregled u vašem alatu za izradu:

Smisao staginga je da se ponaša kao produkcija — isti kod, isti stack, ista vrsta postavki — ali greška tamo nikome ne šteti.

Korak 1: Odlučite šta staging mora odgovarati

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

• Isti kod, objavljen na isti način.
• Isti stack i verzije — framework, runtime, tip baze podataka.
• Istu vrstu konfiguracije — iste nazive varijabli okruženja, s test vrijednostima.
• Iste servise — ako produkcija ima web aplikaciju i API, staging ima oboje.

Može se razlikovati po veličini (manji server je u redu) i po podacima.

Korak 2: Napravite kopiju

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

Kako to uradite zavisi od vašeg hosta:

• Hostovi s ugrađenim preview ili staging deployment-ima mogu automatski napraviti jedan za Git granu.
• Hostovi bez toga: napravite drugu aplikaciju ili projekat iz istog koda i deploy-ujte je odvojeno.
• Kod u Gitu: održavajte granu staging ili main koja se deploy-uje na staging, a na produkciju deploy-ujte iz izdanja. Pogledajte kako koristiti Git s aplikacijom izgrađenom AI-jem.

Korak 3: Dajte stagingu vlastitu bazu podataka

Ovo je korak koji vas štiti. Ako staging i produkcija dijele bazu podataka, test koji briše zapise briše prave zapise.

• Napravite odvojenu bazu podataka za staging.
• Popunite je seed podacima — realističnim lažnim zapisima koje AI može generisati za vas.
• Ako vam treba kopija produkcijskih podataka, prvo uklonite ili zamaskirajte imena, e-mail adrese i sve lično.

Napiši seed skriptu koja popunjava praznu bazu podataka realističnim test podacima: 20 kupaca, 50 narudžbi u različitim stanjima i dva admin korisnika. Koristi očigledno lažna imena i e-mail adrese s domenom example.com.

Prije nego što vjerujete postavci, potvrdite na koju bazu podataka se svaka kopija povezuje. Pitajte direktno:

Na koju bazu podataka se ova aplikacija povezuje i odakle dolazi ta postavka? Pokaži mi naziv varijable, a ne lozinku.

Korak 4: Koristite test ključeve i odvojene postavke

Sve što komunicira s eksternim servisom na stagingu treba koristiti test kredencijale:

• Plaćanja u test načinu rada (na primjer Stripe test ključevi), kako se nijedna prava kartica ne bi naplatila.
• E-pošta šalje se na sandbox ili samo na vašu vlastitu adresu, kako kupci nikada ne bi dobili test poruku.
• AI i drugi plaćeni API-ji s odvojenim ključem i niskim limitom potrošnje.
• Webhook-ovi usmjereni na staging URL, a ne na produkciju.

Zadržite iste nazive varijabli u oba okruženja i mijenjajte samo vrijednosti. Tako kod ne mora znati gdje se izvršava. Za više o ovome pogledajte kako čuvati API ključeve sigurnim.

Korak 5: Držite staging privatnim

Staging ne bi trebao biti javan:

• Stavite ga iza prijave, lozinke ili liste dozvoljenih e-mail adresa tima.
• Spriječite tražilice da ga indeksiraju pomoću noindex meta oznake ili X-Robots-Tag zaglavlja.
• Nemojte ga linkovati s vašeg javnog sajta.
• Neka izgleda drugačije — obojeni baner „STAGING“ sprječava testiranje u pogrešnom tabu.

Dodaj jasno žuti baner na vrhu svake stranice koji kaže „STAGING — samo test podaci“ kada je varijabla okruženja APP_ENV jednaka „staging“. U tom slučaju dodaj i noindex meta oznaku.

Korak 6: Uspostavite rutinu objavljivanja

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

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

Zapišite ključne tokove kao kratku test skriptu. Pogledajte kako testirati aplikaciju prije lansiranja za to šta treba uključiti.

Korak 7: Pažljivo radite s promjenama baze podataka

Promjene strukture baze podataka — dodavanje kolone, preimenovanje tabele — mjesto su gdje staging zaista dolazi do izražaja.

• Prvo pokrenite svaku strukturnu promjenu na stagingu.
• Provjerite da su postojeći podaci preživjeli, a ne samo da novi funkcioniraju.
• Napravite sigurnosnu kopiju produkcije prije nego što istu promjenu pokrenete tamo. Pogledajte kako napraviti sigurnosnu kopiju baze podataka aplikacije.
• Birajte promjene koje dodaju, a ne preimenuju ili brišu, kako bi stara verzija i dalje radila ako se vratite.

Primjeri promptova

Objasni šta bi se dogodilo s postojećim podacima da pokrenemo ovu promjenu baze podataka na produkciji. Da li se nešto briše ili preimenuje?

Neka sve postavke specifične za okruženje — URL-ovi API-ja, ključevi, pošiljalac e-pošte, vlastiti URL sajta — dolaze iz varijabli okruženja s istim nazivima na stagingu i produkciji. Navedi ih.

Napiši kratku kontrolnu listu tokova koje trebam testirati na stagingu prije svakog izdanja, na osnovu onoga što ova aplikacija radi.

Česte greške

• Dijeljena baza podataka. Najštetnija greška. Staging uvijek treba svoju bazu.
• Live ključevi na stagingu. Prave naplate, prave e-poruke pravim kupcima.
• Staging se razilazi s produkcijom. Različite verzije ili postavke znače da staging prestaje hvatati probleme.
• Javan, indeksiran staging sajt koji se pojavljuje u rezultatima pretrage pored vašeg pravog.
• Preskakanje staginga za „male“ promjene. I male promjene kvare stvari.
• Testiranje u pogrešnom tabu. Vidljiv baner to rješava.

Kontrolna lista

• Staging koristi isti kod, stack i servise kao produkcija.
• Staging ima vlastitu bazu podataka s test ili očišćenim podacima.
• Plaćanja, e-pošta i plaćeni API-ji koriste test ključeve na stagingu.
• Nazivi varijabli se poklapaju u okruženjima; mijenjaju se samo vrijednosti.
• Staging je iza prijave ili lozinke i nije indeksiran.
• Baner se prikazuje kada ste na stagingu.
• Svako izdanje ide prvo na staging, uz pisanu listu tokova za provjeru.
• Promjene baze podataka se prvo pokreću na stagingu, uz sigurnosnu kopiju produkcije prije izdanja.

Staging na Mythexu

Mythex Publish vam daje jedan živi URL po aplikaciji; nema posebnog prekidača za staging. U praksi imate dvije opcije:

• Pregled kao vaša provjera prije izdanja. Svaki projekat radi u privatnom cloud radnom prostoru s živim pregledom. /test nalaže agentu da klikće kroz njega kao korisnik, a link Share omogućava klijentu ili članu tima da pregleda pregled 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 tom projektu vlastitu bazu podataka i test-ključ tajne, pa ga objavite na vlastitom slug-u. Objavite na njega prije nego što objavite produkcijski projekat.

U svakom slučaju, prije nego što testirate bilo šta destruktivno, pitajte agenta koju bazu podataka koriste pregled i objavljena aplikacija, a za vraćanje loše promjene koristite checkpoint-e. Za širi pregled kako uvesti aplikaciju u produkciju pogledajte kako prebaciti AI prototip u produkciju.

Pitanja