Šta je staging okruženje? Testirajte pre objavljivanja

Staging okruženje je privatna kopija vaše aplikacije, podešena što sličnije živoj verziji, u kojoj testirate izmene pre nego što ih vide pravi korisnici. Koristi sopstvenu bazu, test podatke i test API ključeve, pa greška u funkciji ili loša izmena podataka tamo ne utiče ni na koga van vašeg tima. Kada izmena izgleda dobro u stagingu, puštate je u produkciju — živu aplikaciju koju koriste vaši klijenti.

Zašto je staging važan kad pravite sa AI

Rad uz AI čini izmene brzim. Možete da dodate funkciju, prepišete stranicu ili promenite strukturu podataka za nekoliko minuta. To je odlično sve dok izmena koja je izgledala dobro tiho ne pokvari plaćanje, ili dok „mala sređivanja” ne obrišu kolonu sa podacima klijenata.

Mesto za proveru izmena pre nego što stignu uživo pomaže vam da:

• Uhvatite kvar pre klijenata. Isprobajte prijavu, plaćanje i ključne tokove nakon svake važnije izmene.
• Testirate u realnim uslovima. Staging treba da se ponaša kao produkcija — isti stack, slična konfiguracija — kako bi se problemi pojavili tamo, a ne kasnije.
• Zaštitite prave podatke. Izmene baze, uvozi i masovne izmene mogu prvo da se isprobaju na test podacima.
• Prikažete posao u toku. Klijent ili kolega može da pregleda izmenu bez da ona bude javna.

Svakodnevna analogija

Zamislite generalnu probu u pozorištu.

• Razvoj je sala za vežbu: glumci isprobavaju replike, zaustavljaju se, ponavljaju, eksperimentišu.
• Staging je generalna proba: pun kostim, prava scena, prava svetla — sve kao na premijeri, samo bez publike koja plaća.
• Produkcija je premijera. Greške se dešavaju pred svima.

Većina problema koje ne želite na premijeri pojavi se na generalnoj probi: presvlačenje koje traje predugo, pogrešno svetlo. Upravo to je posao staginga.

Tri uobičajena okruženja

Okruženja se razlikuju pre svega po konfiguraciji: na koju bazu se povezuju, koje ključeve koriste, na kojoj adresi žive. Zato dobre aplikacije čitaju ta podešavanja iz promenljivih okruženja i tajni umesto da ih upisuju direktno u kod. Isti kod tada može da radi u svakom okruženju sa drugim podešavanjima.

Radni primer: promena pravila otkazivanja kod aplikacije za rezervacije

Vodite aplikaciju za rezervacije u salonu sa plaćajućim klijentima. Želite da promenite pravilo tako da klijenti mogu da otkažu do 24 sata pre termina, a ne 48, i da se povraćaj novca vrši automatski.

1. Napravite izmenu u razvoju. Zatražite od AI alata izmenu. On ažurira logiku otkazivanja i poziv za povraćaj novca ka vašem provajderu plaćanja.

2. Pustite izmenu u staging. Staging radi isti kod, povezan na staging bazu sa test rezervacijama i ključevima za test režim vašeg provajdera plaćanja.

3. Testirajte prave tokove. Vi i kolega:

• zakažete test termin za sutra i otkažete ga 30 sati ranije — povraćaj treba da se izvrši;
• pokušate da otkažete 10 sati ranije — treba da bude odbijeno uz jasnu poruku;
• proverite da se povraćaj pojavljuje na test kontrolnoj tabli provajdera plaćanja;
• proverite da potvrdna poruka na email-u kaže 24 sata, a ne 48.

4. Pronađite grešku. U stagingu primećujete da pravilo koristi vremensku zonu servera, a ne salona, pa je granica pomerena za sat vremena. Ispravljate je i testirate ponovo.

5. Pustite u produkciju. Tek sada izmena stiže do pravih klijenata — sa greškom u vremenskoj zoni već uhvaćenom.

Bez staginga, korak 4 bi se dogodio sa pravim povraćajem novca za pravog klijenta.

Ključni pojmovi

Česte zablude

• „Staging može da deli produkcijsku bazu.” Ovo je najopasniji prečac. Test koji briše ili menja zapise udario bi na prave klijente. Dajte stagingu sopstvenu bazu.
• „Ako radi u stagingu, ne može da se pokvari u produkciji.” Staging smanjuje rizik, ali ga ne uklanja. Pravi saobraćaj, pravi podaci i spoljni servisi i dalje mogu da iznenade. Zadržite način za vraćanje.
• „Staging mora da bude skup.” Može da bude mali. Treba da ima isto podešavanje kao produkcija, ne istu veličinu.
• „Koristite žive ključeve za plaćanje u stagingu da bude realističnije.” Koristite test režim provajdera. Realno ne znači pravi novac.
• „Staging je samo za velike timove.” Ideja — prvo testirati na bezbednom mestu — korisna je i za jednu osobu. Obim formalnosti može da prati ono što je u pitanju.
• „Staging treba da bude javan da bi ljudi mogli da ga isprobaju.” Držite ga privatnim ili zaštićenim i sprečite pretraživače da ga indeksiraju, kako ga niko ne bi zamenio sa pravom aplikacijom.

Šta tražiti od AI alata

• „Sva podešavanja specifična za okruženje — bazu, API ključeve, adresu sajta — neka dolaze iz promenljivih okruženja.”
• „Dodaj seed skriptu koja puni bazu koja nije produkcijska realističnim test podacima.”
• „Koristi test režim provajdera plaćanja dok ne kažem da lansiramo.”
• „Pre nego što ova izmena ode uživo, navedi tokove koje treba da testiram i šta treba da se desi u svakom.”
• „Da li će ova izmena uticati na postojeće podatke? Prvo mi pokaži migraciju.”
• „Proveri da kopije sajta koje nisu produkcijske ne indeksira pretraživač.”

Za korak-po-korak podešavanje pogledajte kako podesiti staging okruženje. Kada izdanja postanu česta, automatizacija puta od koda do staginga i produkcije je ono čemu služi CI/CD.

Testiranje pre objavljivanja u Mythex-u

Mythex nema zaseban prekidač „staging ili produkcija”; objavljivanje vam daje jednu živu javnu URL adresu, a dokumentacija to jasno kaže (aplikacije sa više servisa). Ono što daje jeste jasna granica između izrade i puštanja uživo:

• Preview pokreće vašu aplikaciju u privatnom cloud sandbox-u dok gradite. Izmene se prvo pojavljuju tamo, a ne na živoj aplikaciji.
• Share pravi linkove za pregled da klijent ili kolega može da pregleda posao u toku bez Mythex naloga i bez objavljivanja. Link prikazuje sandbox onakav kakav je sada, uključujući izmene usred izrade, i možete ga obrisati u bilo kom trenutku.
• Publish pravi snimak projekta i postavlja ga. Dok ponovo ne objavite, živa aplikacija ostaje kakva je bila.
• Checkpoints se čuvaju nakon svakog uspešnog koraka agenta, pa možete da vratite fajlove projekta ako izmena pođe po zlu.

Preview tretirajte kao generalnu probu: držite provajdere plaćanja u test režimu do lansiranja i prođite kroz ključne tokove pre svake objave. Kada su uključeni pravi klijenti, pitajte agenta koju bazu i koje ključeve vaš Preview koristi pre nego što testirate bilo šta što upisuje ili briše podatke. Ako vam treba potpuno odvojeno staging podešavanje sa sopstvenom bazom, zamolite agenta da objasni opcije za vaš projekat ili — na Pro planu — izvezite projekat ili ga sinhronizujete sa GitHub-om i pokrenete ga na infrastrukturi koju vi kontrolišete.

Pitanja