Kas yra staging aplinka? Testuokite prieš paleidimą

Staging aplinka – tai privati jūsų programos kopija, kuo artimesnė tiesioginei versijai, kurioje testuojate pakeitimus prieš tai, kai juos pamato tikri vartotojai. Ji naudoja savo duomenų bazę, testinius duomenis ir testinius API raktus, todėl sugedusi funkcija ar blogas duomenų pakeitimas ten neturi įtakos niekam už jūsų komandos ribų. Kai pakeitimas atrodo teisingas staging aplinkoje, jį išleidžiate į production – tiesioginę programą, kuria naudojasi jūsų klientai.

Kodėl staging svarbu kuriant su DI

Kuriant su DI pakeitimai vyksta greitai. Galite pridėti funkciją, perrašyti puslapį ar pakeisti duomenų struktūrą per kelias minutes. Tas greitis puikus, kol pakeitimas, atrodantis tvarkingas, tyliai sugenda atsiskaitymą arba „nedidelis valymas“ ištrina klientų duomenų stulpelį.

Vieta pakeitimams patikrinti prieš juos tampant tiesioginiais padeda:

• Pagauti gedimus anksčiau nei klientus. Po kiekvieno reikšmingo pakeitimo išbandykite registracijos, mokėjimo ir pagrindinius srautus.
• Testuoti realiomis sąlygomis. Staging turi elgtis kaip production – ta pati sistema, panaši konfigūracija – kad problemos pasirodytų ten, o ne vėliau.
• Apsaugoti tikrus duomenis. Duomenų bazės pakeitimus, importus ir masinius redagavimus galima pirmiausia išbandyti testiniuose duomenyse.
• Rodyti darbą, kuris dar nebaigtas. Klientas ar kolega gali peržiūrėti pakeitimą, nesant jo viešai.

Kasdienė analogija

Pagalvokite apie teatro generalinę repeticiją.

• Kūrimas – tai repeticijų salė: aktoriai mokosi tekstus, sustoja, pradeda iš naujo, eksperimentuoja.
• Staging – tai generalinė repeticija: pilnas kostiumas, tikra scena, tikri šviesos efektai – viskas taip, kaip bus premjeros vakarą, tik be mokančios publikos.
• Production – tai premjeros vakaras. Klaidos įvyksta visų akivaizdoje.

Dauguma problemų, kurių nenorėtumėte premjeros vakarą, pasirodo generalinėje: per ilgai trunkantis kostiumo keitimas ar neteisingas šviesos signalas. Būtent tam ir skirtas staging.

Trys įprastos aplinkos

Aplinkos skiriasi daugiausia savo konfigūracija: prie kurios duomenų bazės jungiamasi, kokius raktus naudoja, kokiu URL pasiekiama. Todėl geros programos šiuos nustatymus skaito iš aplinkos kintamųjų ir paslapčių, o ne įrašo tiesiai į kodą. Tas pats kodas tuomet gali veikti kiekvienoje aplinkoje su skirtingais nustatymais.

Pavyzdys: grojimo taisyklių keitimas rezervacijų programoje

Turite grožio salono rezervacijų programą su mokančiais klientais. Norite pakeisti taisyklę, kad klientai galėtų atšaukti likus 24 valandoms, o ne 48, ir pinigai būtų grąžinami automatiškai.

1. Kurkite kūrimo aplinkoje. Paprašote DI kūrėjo pakeitimo. Jis atnaujina atšaukimo logiką ir pinigų grąžinimo užklausą jūsų mokėjimo paslaugos teikėjui.

2. Išleiskite į staging. Staging veikia su tuo pačiu kodu, prijungtas prie staging duomenų bazės su testinėmis rezervacijomis ir jūsų mokėjimo teikėjo testinio režimo raktais.

3. Testuokite tikrus srautus. Jūs ir kolega:

• rezervuojate testinį vizitą rytojui ir atšaukiate 30 valandų iki jo – pinigai turi būti grąžinti;
• bandote atšaukti likus 10 valandų – turi būti atmesta su aiškiu pranešimu;
• patikrinate, ar grąžinimas atsirado mokėjimo teikėjo testinėje panelėje;
• patikrinate, ar patvirtinimo laiške nurodyta 24 valandos, o ne 48.

4. Randate klaidą. Staging aplinkoje pastebite, kad taisyklė naudoja serverio laiko juostą, o ne salono, todėl riba nukrypsta viena valanda. Ją ištaisote ir testuojate iš naujo.

5. Išleidžiate į production. Tik dabar pakeitimas pasiekia tikrus klientus – laiko juostos klaida jau pagauta.

Be staging 4 žingsnis būtų įvykęs su tikro kliento pinigų grąžinimu.

Pagrindiniai terminai

Dažni mitai

• „Staging gali naudoti production duomenų bazę.“ Tai pavojingiausias trumpas kelias. Testas, kuris ištrina ar redaguoja įrašus, paveiktų tikrus klientus. Suteikite staging savo duomenų bazę.
• „Jei veikia staging, production negali sugesti.“ Staging mažina riziką, bet jos nepašalina. Tikras srautas, tikri duomenys ir išoriniai servisai vis tiek gali nustebinti. Turėkite galimybę grįžti atgal.
• „Staging turi būti brangus.“ Jis gali būti mažas. Jam reikia tokios pačios sąrankos kaip production, o ne tokio paties dydžio.
• „Staging naudokite tikrus mokėjimo raktus, kad būtų realiau.“ Naudokite teikėjo testinį režimą. Realumas nereiškia tikrų pinigų.
• „Staging skirtas tik didelėms komandoms.“ Idėja – testuoti saugioje vietoje – naudinga net vienam žmogui. Formalumų kiekis gali priklausyti nuo to, kiek daug rizikuojama.
• „Staging turėtų būti viešas, kad žmonės galėtų jį išbandyti.“ Laikykite jį privatų arba apsaugotą ir neleiskite paieškos sistemoms jo indeksuoti, kad niekas nesupainiotų su tikra programa.

Ką paprašyti DI kūrėjo

• „Kiekvieną aplinkai specifinį nustatymą – duomenų bazę, API raktus, svetainės URL – paimk iš aplinkos kintamųjų.“
• „Pridėk pradinių duomenų skriptą, kuris užpildo ne production duomenų bazę realistiškais testiniais duomenimis.“
• „Naudok mokėjimo teikėjo testinį režimą, kol nepasakysiu, kad paleidžiame.“
• „Prieš šį pakeitimą išleidžiant, išvardink srautus, kuriuos turėčiau patikrinti, ir ką kiekviename iš jų turėtų matyti.“
• „Ar šis pakeitimas paveiks esamus duomenis? Pirmiausia parodyk migraciją.“
• „Įsitikink, kad ne production svetainių kopijų paieškos sistemos neindeksuoja.“

Žingsnis po žingsnio sąrankai žr. kaip nustatyti staging aplinką. Kai išleidimai tampa dažni, kelio nuo kodo iki staging ir production automatizavimas yra tai, kam skirtas CI/CD.

Testavimas prieš išleidimą Mythex platformoje

Mythex neturi atskiro „staging ar production“ jungiklio; paskelbimas suteikia vieną tiesioginį viešą URL, ir dokumentacija tai aiškiai nurodo (kelių paslaugų programos). Tačiau ji suteikia aiškią ribą tarp kūrimo ir tiesioginio paleidimo:

• Peržiūra (Preview) paleidžia jūsų programą privačioje debesies smėlio dėžėje kūrimo metu. Pakeitimai pirmiausia matomi ten, o ne jūsų tiesioginėje programoje.
• Bendrinimas (Share) sukuria peržiūros nuorodas, kad klientas ar kolega galėtų peržiūrėti darbą be Mythex paskyros ir be jūsų paskelbimo. Nuoroda rodo smėlio dėžę tokią, kokia ji yra dabar, įskaitant nebaigtus pakeitimus, ir ją bet kada galite ištrinti.
• Paskelbimas (Publish) padaro projekto momentinę kopiją ir ją įdiegia. Kol neskelbiate iš naujo, tiesioginė programa lieka tokia, kokia buvo.
• Kontrolės taškai (Checkpoints) išsaugomi po kiekvieno sėkmingo agento ėjimo, todėl galite grąžinti projekto failus, jei pakeitimas nepavyksta.

Traktuokite Preview kaip savo repeticiją: mokėjimo teikėjus laikykite testiniame režime iki paleidimo ir prieš kiekvieną paskelbimą praeikite pagrindinius srautus. Kai jau yra tikrų klientų, prieš testuojant bet ką, kas rašo ar trina duomenis, pokalbyje paklauskite agento, kokią duomenų bazę ir raktus naudoja jūsų Preview. Jei reikia visiškai atskiros staging sąrankos su savo duomenų baze, paprašykite agento paaiškinti jūsų projekto parinktis arba – Pro plane – eksportuokite projektą ar susiekite jį su GitHub ir paleiskite infrastruktūroje, kurią valdote.

Klausimai