Šta je staging okruženje? Testirajte prije objavljivanja

Staging okruženje je privatna kopija vaše aplikacije, postavljena što je moguće bliže živoj verziji, u kojoj testirate promjene prije nego što ih vide pravi korisnici. Koristi svoju bazu, testne podatke i testne API ključeve, pa neispravna funkcija ili loša promjena podataka tamo ne utiče ni na koga izvan vašeg tima. Kada se promjena u stagingu pokaže ispravnom, puštate je u produkciju — živu aplikaciju koju koriste vaši kupci.

Zašto je staging važan kada pravite uz AI

Pravljenje uz AI čini promjene brzim. Možete dodati funkciju, prepisati stranicu ili promijeniti strukturu podataka za nekoliko minuta. Ta brzina je odlična, dok promjena koja je izgledala dobro ne pokvari tiho plaćanje, ili „mala sređivanja” ne obrišu kolonu s podacima kupaca.

Mjesto za provjeru promjena prije nego što odu u javnost pomaže vam da:

• Uhvatite kvarove prije kupaca. Isprobajte tokove prijave, plaćanja i ključne tokove nakon svake značajnije promjene.
• Testirate u realnim uslovima. Staging treba da se ponaša kao produkcija — isti stack, slična konfiguracija — pa se problemi pokažu tamo, a ne kasnije.
• Zaštitite prave podatke. Promjene baze, uvoz i masovne izmjene mogu se prvo isprobati na testnim podacima.
• Pokažete rad u toku. Klijent ili kolega može pregledati promjenu bez da ona bude javna.

Analogija iz svakodnevnog života

Zamislite generalnu probu u pozorištu.

• Razvoj je prostorija za probe: glumci uče tekst, zaustavljaju se, ponavljaju, isprobavaju.
• Staging je generalna proba: puni kostimi, pravi scenski prostor, prava rasvjeta — sve kao što će biti na premijeri, osim što nema plaćajuće publike.
• Produkcija je premijera. Greške se dešavaju pred svima.

Većina problema koje ne želite na premijeri pokaže se na generalnoj probi: predugačka promjena kostima ili pogrešan svjetlosni signal. To je upravo posao stagea.

Tri uobičajena okruženja

Okruženja se razlikuju prvenstveno po konfiguraciji: na koju bazu se povezuju, koje ključeve koriste, na kojoj adresi žive. Zato dobre aplikacije čitaju te postavke iz varijabli okruženja i tajni, a ne da ih upisuju direktno u kod. Isti kod tada može raditi u svakom okruženju s različitim postavkama.

Radni primjer: promjena pravila otkazivanja u aplikaciji za zakazivanje

Vodite aplikaciju za zakazivanje termina u salonu s plaćajućim kupcima. Želite promijeniti pravilo da kupci mogu otkazati do 24 sata prije termina, umjesto 48, i da se povrati novac dešavaju automatski.

1. Napravite promjenu u razvoju. Zatražite promjenu od AI alata. On ažurira logiku otkazivanja i poziv za povrat novca prema vašem dobavljaču plaćanja.

2. Pustite promjenu u staging. Staging pokreće isti kod, povezan na staging bazu s testnim terminima i ključevima testnog režima vašeg dobavljača plaćanja.

3. Testirajte prave tokove. Vi i kolega:

• zakažete testni termin za sutra i otkažete ga 30 sati prije — novac bi trebalo da se vrati;
• pokušate otkazati 10 sati prije — trebalo bi da bude odbijeno uz jasnu poruku;
• provjerite da se povrat pojavljuje u testnoj kontrolnoj tabli dobavljača plaćanja;
• provjerite da potvrdna e-pošta kaže 24 sata, a ne 48.

4. Pronađite grešku. U stagingu primijetite da pravilo koristi vremensku zonu servera, a ne salona, pa je granica sat vremena pogrešna. Ispravite i ponovo testirate.

5. Pustite u produkciju. Tek sada promjena stiže do pravih kupaca — s greškom u vremenskoj zoni već uhvaćenom.

Bez stagea, korak 4 bi se dogodio s pravim povratom novca za pravog kupca.

Ključni pojmovi

Česte zablude

• „Staging može dijeliti produkcijsku bazu.” Ovo je najopasniji prečac. Test koji briše ili mijenja zapise pogodio bi prave kupce. Dajte stagingu vlastitu bazu.
• „Ako radi u stagingu, ne može se pokvariti u produkciji.” Staging smanjuje rizik, ali ga ne uklanja. Pravi saobraćaj, pravi podaci i vanjski servisi i dalje mogu iznenaditi. Zadržite način za vraćanje na prethodnu verziju.
• „Staging mora biti skup.” Može biti mali. Treba mu ista postavka kao produkciji, a ne ista veličina.
• „Koristite žive ključeve za plaćanje u stagingu da bude realističnije.” Koristite testni režim dobavljača. Realno ne znači pravi novac.
• „Staging je samo za velike timove.” Ideja — prvo testirati na sigurnom mjestu — korisna je i za jednu osobu. Obim formalnosti može rasti sa ulogom.
• „Staging treba biti javan da ljudi mogu da ga isprobaju.” Držite ga privatnim ili zaštićenim i spriječite tražilice da ga indeksiraju, da ga niko ne bi zamijenio za pravu aplikaciju.

Šta tražiti od vašeg AI alata

• „Neka svaka postavka specifična za okruženje — baza, API ključevi, URL sajta — dolazi iz varijabli okruženja.”
• „Dodaj seed skriptu koja puni neproduktivnu bazu realističnim testnim podacima.”
• „Koristi testni režim dobavljača plaćanja dok ne kažem da lansiramo.”
• „Prije nego što ova promjena ode u javnost, navedi tokove koje treba testirati i šta se u svakom treba dogoditi.”
• „Hoće li ova promjena uticati na postojeće podatke? Prvo mi pokaži migraciju.”
• „Pobrini se da nepročitane kopije sajta ne indeksiraju tražilice.”

Za postavljanje korak po korak pogledajte kako postaviti staging okruženje. Kada objave postanu česte, automatizacija puta od koda do stagea i produkcije je ono čemu služi CI/CD.

Testiranje prije objave u Mythexu

Mythex nema zasebno prekidač „staging ili produkcija”; objavljivanje vam daje jedan živi javni URL, a dokumentacija to jasno kaže (aplikacije s više servisa). Ono što daje je jasna granica između pravljenja i puštanja u javnost:

• Preview pokreće vašu aplikaciju u privatnom oblaku dok pravite. Promjene se prvo pojavljuju tamo, a ne u vašoj živoj aplikaciji.
• Share pravi linkove za pregled da klijent ili kolega može pregledati rad u toku bez Mythex naloga i bez vaše objave. Link prikazuje sandbox onakav kakav je upravo sada, uključujući promjene usred izrade, a možete ga obrisati u bilo kom trenutku.
• Publish snima projekat i objavljuje ga. Dok ponovo ne objavite, živa aplikacija ostaje kakva je bila.
• Checkpoint-i se čuvaju nakon svakog uspješnog koraka agenta, pa možete vratiti fajlove projekta ako promjena krene pogrešno.

Preview koristite kao probu: držite dobavljače plaćanja u testnom režimu do lansiranja i prođite kroz ključne tokove prije svake objave. Kada su uključeni pravi kupci, provjerite s agentom koju bazu i ključeve vaš Preview koristi prije testiranja bilo čega što piše ili briše podatke. Ako vam treba potpuno odvojen staging s vlastitom bazom, zatražite od agenta da objasni opcije za vaš projekat, ili — na Pro planu — izvezite projekat ili ga sinhronizujte s GitHubom i pokrenite na infrastrukturi koju kontrolišete.

Pitanja