Kako postaviti staging okruženje za svoju aplikaciju

Da biste postavili staging okruženje, objavite drugu kopiju aplikacije na vlastiti privatni URL, dajte joj vlastitu bazu podataka i testne API ključeve te je što je moguće više uskladite s postavkama produkcije. Zatim svaku važniju promjenu najprije objavite na stagingu, prođite kroz ključne tokove i na produkciju objavljujte tek kada staging izgleda ispravno.

Ako vam je ideja nova, što je staging okruženje objašnjava koncept. Ovaj vodič je praktično postavljanje, namijenjeno ljudima koji grade s AI alatima, a ne timovima za DevOps.

Razvoj, staging i produkcija

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

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

Korak 1: Odredite čemu staging mora odgovarati

Staging je koristan samo ako se problemi pokažu tamo prije nego što se pokažu u produkciji. Uskladite:

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

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

Korak 2: Napravite kopiju

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

Kako to napraviti ovisi o vašem hostu:

• Hostovi s ugrađenim pregledima ili staging postavljanjima mogu ga automatski stvoriti za Git granu.
• Hostovi bez toga: napravite drugu aplikaciju ili projekt iz istog koda i postavite ga zasebno.
• Kod u Gitu: držite granu staging ili main koja se postavlja na staging, a na produkciju postavljajte iz izdanja. Pogledajte kako koristiti Git s aplikacijom izrađ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 zasebnu bazu podataka za staging.
• Napunite je seed podacima — realistično izgledajućim lažnim zapisima koje AI može generirati za vas.
• Ako su vam potrebni podaci iz produkcije, prije toga uklonite ili izmiješajte imena, e-adrese i sve osobno.

Napiši seed skriptu koja praznu bazu podataka puni realističnim testnim podacima: 20 kupaca, 50 narudžbi u različitim stanjima i dva administratorska korisnika. Koristi očito lažna imena i adrese e-pošte na example.com.

Prije nego što se oslonite na postavku, potvrdite na koju bazu se svaka kopija spaja. Pitajte izravno:

S kojom bazom podataka se ova aplikacija spaja i odakle dolazi ta postavka? Pokaži mi naziv varijable, ne lozinku.

Korak 4: Koristite testne ključeve i zasebne postavke

Sve što komunicira s vanjskom uslugom na stagingu treba koristiti testne vjerodajnice:

• Plaćanja u testnom načinu (na primjer Stripe testni ključevi), tako da se nijedna prava kartica ne tereti.
• E-pošta šalje se u sandbox ili samo na vašu adresu, tako da kupci nikada ne dobiju testnu poruku.
• AI i druge plaćene API-je s posebnim ključem i niskim ograničenjem potrošnje.
• Webhookovi 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 izvodi. Za više o tome pogledajte kako čuvati API ključeve sigurnima.

Korak 5: Držite staging privatnim

Staging ne bi trebao biti javan:

• Stavite ga iza prijave, lozinke ili popisa dopuštenih e-adresa tima.
• Spriječite indeksiranje u tražilicama oznakom noindex u meta tagu ili zaglavljem X-Robots-Tag.
• Nemojte ga povezivati s vašom javnom stranicom.
• Neka izgleda drugačije — obojeni banner "STAGING" sprječava testiranje u pogrešnoj kartici.

Dodaj upadljivi žuti banner na vrh svake stranice s tekstom "STAGING — samo testni podaci" kada varijabla okruženja APP_ENV ima vrijednost "staging". U tom slučaju dodaj i meta tag noindex.

Korak 6: Uspostavite rutinu objave

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

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

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

Korak 7: Pažljivo radite s promjenama baze podataka

Promjene strukture baze podataka — dodavanje stupca, preimenovanje tablice — mjesto su na kojem se staging isplati.

• Svaku promjenu strukture najprije pokrenite na stagingu.
• Provjerite da su postojeći podaci preživjeli, a ne samo to rade li nove značajke.
• Napravite sigurnosnu kopiju produkcije prije nego što istu promjenu pokrenete tamo. Pogledajte kako napraviti sigurnosnu kopiju baze podataka aplikacije.
• Dajte prednost promjenama koje dodaju umjesto onih koje preimenuju ili brišu, kako bi stara verzija i dalje radila ako se vraćate unatrag.

Primjeri upita

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

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

Napiši kratki kontrolni popis tokova koje trebam testirati na stagingu prije svakog izdanja, na temelju onoga što ova aplikacija radi.

Česte pogreške

• Zajednička baza podataka. Najštetnija pogreška. Staging uvijek dobiva vlastitu.
• Živi ključevi na stagingu. Prave naplate, prava e-pošta pravim kupcima.
• Staging se razilazi s produkcijom. Različite verzije ili postavke znače da staging prestaje hvatati probleme.
• Javni, indeksirani staging site koji se pojavljuje u rezultatima pretraživanja pored vašeg pravog.
• Preskakanje staginga za "male" promjene. I male promjene lome stvari.
• Testiranje u pogrešnoj kartici. Vidljivi banner to rješava.

Kontrolni popis

• Staging koristi isti kod, stack i usluge kao produkcija.
• Staging ima vlastitu bazu podataka s testnim ili očišćenim podacima.
• Plaćanja, e-pošta i plaćeni API-ji na stagingu koriste testne ključeve.
• Nazivi varijabli se podudaraju između okruženja; razlikuju se samo vrijednosti.
• Staging je iza prijave ili lozinke i nije indeksiran.
• Banner se prikazuje kada ste na stagingu.
• Svako izdanje ide najprije na staging, uz napisan popis tokova za provjeru.
• Promjene baze podataka najprije se izvode na stagingu, uz sigurnosnu kopiju produkcije prije izdanja.

Staging na Mythexu

Mythexov Publish daje vam jedan živi URL po aplikaciji; ne postoji zasebni prekidač za staging. U praksi imate dvije mogućnosti:

• Pregled kao pretpredajna provjera. Svaki projekt radi u privatnom oblačnom radnom prostoru s živim pregledom. /test omogućuje agentu da klikće kroz njega kao korisnik, a veza Share omogućuje klijentu ili suradniku da pregleda pregled bez objave. Pogledajte Preview and Code. Za mnoge samostalne projekte to je dovoljno.
• Drugi projekt kao staging. Na Pro planu izvezite projekt i uvezite ga u novi projekt, dajte tom projektu vlastitu bazu podataka i tajne s testnim ključevima te ga objavite na vlastitom slugu. Objavite na njemu prije nego što objavite produkcijski projekt.

U oba slučaja, prije nego što nešto destruktivno testirate, pitajte agenta koju bazu podataka koriste pregled i objavljena aplikacija te koristite checkpointe za vraćanje lošeg izmjena. Za širi pregled kako lansirati aplikaciju uživo pogledajte kako prenijeti AI prototip u produkciju.

Pitanja