Što je staging okruženje? Testirajte prije objave

Staging okruženje je privatna kopija vaše aplikacije, postavljena što sličnije živoj verziji, na kojoj testirate promjene prije nego ih vide pravi korisnici. Koristi vlastitu bazu podataka, testne podatke i testne API ključeve, pa pokvarena značajka ili loša promjena podataka tamo ne utječe ni na koga izvan vašeg tima. Kada promjena na stagingu izgleda ispravno, objavljujete je u produkciji — živoj aplikaciji koju koriste vaši kupci.

Zašto je staging važan kad gradite s AI-jem

Gradnja uz AI čini promjene brzima. Možete dodati značajku, prepisati stranicu ili promijeniti strukturu podataka u nekoliko minuta. Ta brzina je odlična sve dok promjena koja je izgledala dobro tiho ne pokvari plaćanje ili dok „mala čistka“ ne obriše stupac s podacima kupaca.

Mjesto za provjeru promjena prije objave pomaže vam da:

• Uhvatite kvar prije kupaca. Isprobajte prijavu, plaćanje i ključne tokove nakon svake važnije promjene.
• Testirate u stvarnim uvjetima. Staging se treba ponašati kao produkcija — isti stack, slična konfiguracija — kako se problemi pokažu tamo, a ne kasnije.
• Zaštitite stvarne podatke. Promjene baze, uvozi i masovne izmjene mogu se prvo uvježbati na testnim podacima.
• Pokažete rad u tijeku. Klijent ili kolega može pregledati promjenu bez da je javna.

Svakodnevna usporedba

Zamislite generalnu probu u kazalištu.

• Razvoj je prostorija za probe: glumci isprobavaju replike, zaustavljaju se, ponavljaju, eksperimentiraju.
• Staging je generalna proba: pune kostime, prava pozornica, prava rasvjeta — sve kao što će biti na premijeri, samo bez publike koja plaća.
• Produkcija je premijera. Greške se događaju pred svima.

Većina problema koje ne biste željeli na premijeri pojavi se na generalnoj probi: presvlačenje koje traje predugo, pogrešan svjetlosni signal. Upravo je to posao stagea.

Tri uobičajena okruženja

Svako okruženje se razlikuje prvenstveno po konfiguraciji: na koju bazu se spaja, koje ključeve koristi, na kojoj adresi živi. Zato dobre aplikacije čitaju te postavke iz varijabli okruženja i tajni, umjesto da ih tvrdo kodiraju. Isti kod tada može raditi u svakom okruženju s drugim postavkama.

Primjer: promjena pravila otkazivanja u aplikaciji za rezervacije

Vodite aplikaciju za rezervacije u frizerskom salonu s plaćajućim kupcima. Želite promijeniti pravilo da kupci mogu otkazati do 24 sata prije termina, a ne 48, i da se povrat novca odvija automatski.

1. Izgradite u razvoju. Zatražite promjenu od AI graditelja. On ažurira logiku otkazivanja i poziv za povrat novca prema vašem pružatelju plaćanja.

2. Objavite na stagingu. Staging pokreće isti kod, spojen na staging bazu s testnim rezervacijama i ključevima za testni način vašeg pružatelja plaćanja.

3. Testirajte stvarne tokove. Vi i kolega:

• rezervirate testni termin za sutra i otkažete ga 30 sati ranije — trebao bi se vratiti novac;
• pokušate otkazati 10 sati ranije — trebalo bi biti odbijeno uz jasnu poruku;
• provjerite pojavljuje li se povrat u testnoj nadzornoj ploči pružatelja plaćanja;
• provjerite piše li potvrdna e-poruka 24 sata, a ne 48.

4. Pronađite grešku. Na stagingu primjećujete da pravilo koristi vremensku zonu poslužitelja, a ne salona, pa je granica pomaknuta za sat vremena. Ispravljate je i ponovno testirate.

5. Objavite u produkciji. Tek sada promjena stiže do pravih kupaca — greška s vremenskom zonom već je uhvaćena.

Da nema stagea, korak 4 bi se dogodio s povratom novca pravom kupcu.

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 na stagingu, ne može se pokvariti u produkciji.“ Staging smanjuje rizik, ali ga ne uklanja. Stvarni promet, pravi podaci i vanjske usluge i dalje mogu iznenaditi. Zadržite način za vraćanje.
• „Staging mora biti skup.“ Može biti mali. Treba imati isto postavljanje kao produkcija, a ne istu veličinu.
• „Koristite žive ključeve za plaćanje na stagingu da bude realističnije.“ Koristite testni način pružatelja. Realistično ne znači pravi novac.
• „Staging je samo za velike timove.“ Ideja — prvo testiraj na sigurnom mjestu — korisna je i za jednu osobu. Razina formalnosti može rasti s ulogom.
• „Staging treba biti javan da ga ljudi mogu isprobati.“ Držite ga privatnim ili zaštićenim i spriječite tražilice da ga indeksiraju, kako ga nitko ne bi zamijenio za pravu aplikaciju.

Što tražiti od vašeg AI graditelja

• „Neka sve postavke specifične za okruženje — bazu, API ključeve, URL stranice — dolaze iz varijabli okruženja.“
• „Dodaj seed skriptu koja napuni bazu koja nije produkcijska realističnim testnim podacima.“
• „Koristi testni način pružatelja plaćanja dok ne kažem da lansiramo.“
• „Prije nego ova promjena ode u produkciju, popiši tokove koje trebam testirati i što se u svakom treba dogoditi.“
• „Hoće li ova promjena utjecati na postojeće podatke? Prvo mi pokaži migraciju.“
• „Pobrini se da kopije stranice koje nisu produkcijske ne indeksiraju tražilice.“

Za korak-po-korak postavljanje pogledajte kako postaviti staging okruženje. Kada promjene postanu česte, automatiziranje puta od koda do stagea i produkcije upravo je zadatak za CI/CD.

Testiranje prije objave u Mythexu

Mythex nema zasebni prekidač „staging nasuprot produkciji“; objava 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 gradnje i lansiranja:

• Pregled pokreće vašu aplikaciju u privatnom oblaku dok gradite. Promjene se prvo pojavljuju tamo, a ne u živoj aplikaciji.
• Dijeljenje stvara poveznice za pregled kako klijent ili kolega može pregledati rad u tijeku bez Mythex računa i bez vaše objave. Poveznica prikazuje pješčanik onakav kakav jest u tom trenutku, uključujući promjene usred gradnje, a možete je obrisati u bilo kojem trenutku.
• Objava snima projekt i postavlja ga. Dok ponovno ne objavite, živa aplikacija ostaje kakva je bila.
• Kontrolne točke se spremaju nakon svakog uspješnog koraka agenta, pa možete vratiti datoteke projekta ako promjena pođe po zlu.

Pregled tretirajte kao svoju probu: pružatelje plaćanja držite u testnom načinu do lansiranja i prođite ključne tokove prije svake objave. Kad su uključeni pravi kupci, prije testiranja bilo čega što piše ili briše podatke provjerite s agentom koju bazu i ključeve vaš Pregled koristi. Ako vam treba potpuno zasebno staging postavljanje s vlastitom bazom, zamolite agenta da objasni vaše mogućnosti za vaš projekt ili — u Pro planu — izvezite projekt ili ga sinkronizirajte s GitHubom te pokrenite na infrastrukturi koju kontrolirate.

Pitanja