Kaj je okolje za predprodukcijo (staging)? Preizkusite, preden greste v živo

Okolje za predprodukcijo (staging) je zasebna kopija vaše aplikacije, nastavljena čim bližje živi različici, kjer preizkušate spremembe, preden jih vidijo pravi uporabniki. Uporablja svojo bazo podatkov, testne podatke in testne API-ključe, zato pokvarjena funkcija ali slaba sprememba podatkov tam ne prizadene nikogar zunaj vaše ekipe. Ko je sprememba na predprodukciji videti pravilna, jo izdate v produkcijo — živo aplikacijo, ki jo uporabljajo vaše stranke.

Zakaj je predprodukcija pomembna pri gradnji z AI

Gradnja z AI omogoča hitre spremembe. Funkcijo dodate, stran prepišete ali spremenite strukturo podatkov v nekaj minutah. To je odlično, dokler sprememba, ki je videti v redu, tiho ne pokvari blagajne ali pa »manjše čiščenje« ne izbriše stolpca s podatki strank.

Mesto za preverjanje sprememb, preden gredo v živo, vam pomaga:

• Ujeti napako, preden jo opazijo stranke. Po vsaki pomembnejši spremembi preizkusite prijavo, plačilo in ključne tokove.
• Preizkusiti v realnih pogojih. Predprodukcija naj se obnaša kot produkcija — isti sklad, podobna konfiguracija —, da se težave pokažejo tam, ne kasneje.
• Zaščititi prave podatke. Spremembe baze, uvoze in množinske urejanja lahko najprej vadite na testnih podatkih.
• Pokazati delo v teku. Stranka ali sodelavec lahko pregleda spremembo, ne da bi bila javno vidna.

Vsakdanja primerjava

Pomislite na generalko v gledališču.

• Razvoj je vadnica: igralci preizkušajo vloge, ustavijo se, začnejo znova, eksperimentirajo.
• Predprodukcija je generalka: pravi kostumi, pravi oder, prava luč — vse, kot bo na premieri, le da ni plačujočega občinstva.
• Produkcija je premiera. Napake se zgodijo pred vsemi.

Večino težav, ki jih na premieri ne bi radi imeli, odkrijete na generalki: predolgo preoblačenje ali napačen znak za luč. To je prav naloga predprodukcije.

Tri pogosta okolja

Vsako okolje se razlikuje predvsem po konfiguraciji: na katero bazo se poveže, katere ključe uporablja, na katerem naslovu teče. Zato dobre aplikacije te nastavitve berejo iz okoljskih spremenljivk in skrivnosti in ne vpisujejo neposredno v kodo. Ista koda se tako lahko izvaja v vsakem okolju z drugačnimi nastavitvami.

Delovni primer: spreminjanje pravil za odpovedi rezervacij v aplikaciji za salon

Vodite aplikacijo za rezervacije v salonu s plačujočimi strankami. Želite spremeniti pravilo, da lahko stranke odpovejo do 24 ur pred terminom, ne 48, povračilo pa je samodejno.

1. Zgradite v razvoju. AI graditelju zastavite spremembo. Ta posodobi logiko odpovedi in klic za povračilo pri vašem ponudniku plačil.

2. Izdajte na predprodukcijo. Predprodukcija izvaja isto kodo, povezano s testno bazo rezervacij in s testnimi ključi vašega ponudnika plačil (testni način).

3. Preizkusite prave tokove. Vi in sodelavec:

• rezervirajte testni termin za jutri in ga odpovejte 30 ur prej — povračilo bi moralo biti izvedeno;
• poskusite odpovedati 10 ur prej — zavrnjeno bi moralo biti z jasnim sporočilom;
• preverite, ali se povračilo pojavi na testni nadzorni plošči ponudnika plačil;
• preverite, ali potrditveni e-poštni sporočilo navaja 24 ur, ne 48.

4. Najdite napako. Na predprodukciji opazite, da pravilo uporablja časovni pas strežnika, ne salona, zato je mejni čas za uro narobe. Popravite in znova preizkusite.

5. Izdajte v produkcijo. Šele zdaj sprememba doseže prave stranke — z napako v časovnem pasu že odkrito.

Brez predprodukcije bi se 4. korak zgodil s pravim povračilom stranki.

Ključni pojmi

Pogoste zmote

• »Predprodukcija lahko deli produkcijsko bazo.« To je najnevarnejša bližnjica. Test, ki izbriše ali popravi zapise, bi zadel prave stranke. Dajte predprodukciji lastno bazo.
• »Če deluje na predprodukciji, se v produkciji ne more pokvariti.« Predprodukcija zmanjša tveganje, ne odpravi ga. Pravi promet, pravi podatki in zunanje storitve vas lahko še vedno presenetijo. Imejte način za vrnitev nazaj.
• »Predprodukcija mora biti draga.« Lahko je majhna. Potrebuje enako postavitev kot produkcija, ne pa enake velikosti.
• »Za realnost uporabite žive ključe plačil na predprodukciji.« Uporabite testni način ponudnika. Realnost ne pomeni pravi denar.
• »Predprodukcija je samo za velike ekipe.« Ideja — preizkusiti nekje varno, preden izdate — je koristna tudi za enega človeka. Obseg postopkov se lahko prilagodi tveganju.
• »Predprodukcija naj bo javna, da jo lahko ljudje preizkusijo.« Ohranite jo zasebno ali zaščiteno in preprečite, da bi jo iskalniki indeksirali, da je nihče ne zamenja za pravo aplikacijo.

Kaj zahtevati od svojega AI graditelja

• „Vse nastavitve, ki so odvisne od okolja — baza, API-ključi, naslov spletnega mesta —, naj prihajajo iz okoljskih spremenljivk.“
• „Dodaj skripto za vzorčne podatke, ki neprodukcijsko bazo napolni z realističnimi testnimi podatki.“
• „Uporabljaj testni način ponudnika plačil, dokler ne rečem, da gremo v živo.“
• „Preden ta sprememba gre v živo, navedi tokove, ki jih moram preizkusiti, in kaj mora v vsakem od njih nastati.“
• „Ali bo ta sprememba vplivala na obstoječe podatke? Najprej mi pokaži migracijo.“
• „Poskrbi, da iskalniki ne indeksirajo neprodukcijskih kopij spletnega mesta.“

Za postopek po korakih glejte kako nastaviti okolje za predprodukcijo. Ko izdaje postanejo pogoste, je avtomatizacija poti od kode do predprodukcije in produkcije naloga CI/CD.

Testiranje pred izdajo v Mythexu

Mythex nima ločenega preklopnika »predprodukcija proti produkciji«; objava vam da en sam javno dostopen živi naslov, dokumentacija pa to jasno pove (aplikacije z več storitvami). Kar ponuja, je jasna meja med gradnjo in objavo v živo:

• Predogled zažene vašo aplikacijo v zasebnem oblaku med gradnjo. Spremembe se najprej pojavijo tam, ne v živi aplikaciji.
• Deljenje ustvari povezave za predogled, da stranka ali sodelavec lahko pregleda delo v teku, ne da bi imel račun pri Mythexu in ne da bi vi objavili. Povezava prikazuje peskovnik takšen, kot je v tem trenutku, vključno s spremembami sredi gradnje, in jo lahko kadar koli izbrišete.
• Objava posname stanje projekta in ga namesti. Dokler ne objavite znova, ostane živa aplikacija takšna, kot je bila.
• Kontrolne točke se shranijo po vsakem uspešnem koraku agenta, da lahko projektne datoteke povrnete, če gre sprememba narobe.

Predogled obravnavajte kot vajo: plačilne ponudnike držite v testnem načinu do izdaje in pred vsako objavo preizkusite ključne tokove. Ko gre za prave stranke, z agentom preverite, katero bazo in katere ključe uporablja vaš predogled, preden preizkusite karkoli, kar piše ali briše podatke. Če potrebujete popolnoma ločeno postavitev za predprodukcijo z lastno bazo, agenta prosite, naj razloži vaše možnosti za vaš projekt, ali pa — na Pro — projekt izvozite ali sinhronizirate z GitHubom in ga poženete na infrastrukturi, ki jo nadzirate.

Vprašanja