Kaip nustatyti programėlės testavimo (staging) aplinką

Norėdami nustatyti staging aplinką, įdiekite antrą programėlės kopiją savo privačiu URL, suteikite jai atskirą duomenų bazę ir bandomuosius API raktus bei padarykite, kad ji kuo labiau atitiktų produkcijos nustatymus. Tada kiekvieną reikšmingą pakeitimą pirmiausia išleiskite į staging, patikrinkite svarbiausius srautus ir į produkciją publikuokite tik tada, kai staging atrodo teisingai.

Jei tai dar naujas dalykas, kas yra staging aplinka paaiškina sąvoką. Šis vadovas – praktinis nustatymas, parengtas žmonėms, kurie kuria su DI įrankiais, o ne žmonėms, kurie valdo DevOps komandą.

Kūrimas, staging ir produkcija

Daugeliui mažų programėlių reikia trijų vietų, net jei pirmoji yra tiesiog jūsų kūrimo įrankio peržiūra:

Staging esmė – elgtis kaip produkcija: tas pats kodas, tas pats steko pagrindas, tokio pat tipo nustatymai, bet klaida ten nieko nepažeidžia.

1 žingsnis. Nuspręskite, ką staging turi atitikti

Staging naudinga tik tada, kai problemos pasirodo ten anksčiau nei produkcijoje. Turi sutapti:

• Tas pats kodas, išleidžiamas tuo pačiu būdu.
• Tas pats stekas ir versijos – karkasas, vykdymo aplinka, duomenų bazės tipas.
• Tokio pat tipo konfigūracija – tie patys aplinkos kintamųjų pavadinimai su bandomosiomis reikšmėmis.
• Tos pačios paslaugos – jei produkcijoje yra žiniatinklio programa ir API, staging taip pat turi abu.

Ji gali skirtis dydžiu (mažesnė mašina tinka) ir duomenimis.

2 žingsnis. Sukurkite kopiją

Paprasčiausias būdas: antras to paties projekto diegimas kitu URL, pavyzdžiui, staging.yourapp.com ar yourapp-staging.example.com.

Kaip tai daryti, priklauso nuo jūsų talpinimo platformos:

• Platformos su įtaisytais peržiūros ar staging diegimais gali sukurti jį automatiškai kiekvienai Git šakai.
• Platformos be to: sukurkite antrą programėlę ar projektą iš to paties kodo ir diegkite atskirai.
• Kodas Git saugykloje: laikykite staging ar main šaką, kuri diegiama į staging, o į produkciją diegite iš išleidimo. Žr. kaip naudoti Git su DI sukurta programėle.

3 žingsnis. Suteikite staging atskirą duomenų bazę

Tai žingsnis, kuris jus apsaugo. Jei staging ir produkcija dalijasi duomenų baze, testas, kuris ištrina įrašus, ištrina tikrus įrašus.

• Sukurkite atskirą duomenų bazę staging aplinkai.
• Užpildykite ją sėklos duomenimis – realistiškais išgalvotais įrašais, kuriuos DI gali sugeneruoti jums.
• Jei reikia produkcijos duomenų kopijos, pirmiausia pašalinkite arba užmaskuokite vardus, el. paštus ir visa, kas asmeniška.

Parašykite sėklos skriptą, kuris užpildo tuščią duomenų bazę realistiškais testiniais duomenimis: 20 klientų, 50 užsakymų skirtingose būsenose ir du administratoriai. Naudokite akivaizdžiai išgalvotus vardus ir example.com el. pašto adresus.

Prieš pasitikėdami nustatymais, patikrinkite, prie kurios duomenų bazės prisijungia kiekviena kopija. Paklauskite tiesiogiai:

Prie kurios duomenų bazės prisijungia ši programėlė ir iš kur ateina šis nustatymas? Parodykite kintamojo pavadinimą, o ne slaptažodį.

4 žingsnis. Naudokite bandomuosius raktus ir atskirus nustatymus

Viskas, kas kalba su išorine paslauga, staging aplinkoje turėtų naudoti testinius prisijungimo duomenis:

• Mokėjimai testo režime (pavyzdžiui, Stripe testiniai raktai), kad jokia tikra kortelė nebūtų apmokestinta.
• El. paštas siunčiamas į smėlio dėžę arba tik į jūsų pačių adresą, kad klientai niekada negautų testinės žinutės.
• DI ir kiti mokami API su atskiru raktu ir žemu išlaidų limitu.
• Webhook'ai nukreipti į staging URL, o ne į produkciją.

Abiejose aplinkose išlaikykite tuos pačius kintamųjų pavadinimus ir keiskite tik reikšmes. Taip kodas nereikia žinoti, kur jis veikia. Daugiau apie tai – kaip saugiai laikyti API raktus.

5 žingsnis. Laikykite staging privačiai

Staging neturėtų būti viešas:

• Apsaugokite jį prisijungimu, slaptažodžiu ar leidžiamų komandos el. paštų sąrašu.
• Sustabdykite paieškos sistemų indeksavimą naudodami noindex meta žymę ar X-Robots-Tag antraštę.
• Nesiekite į jį nuorodų iš savo viešos svetainės.
• Padarykite, kad atrodytų kitaip – spalvota „STAGING“ juosta apsaugo nuo testavimo netinkamame skirtuke.

Kiekvieno puslapio viršuje pridėkite ryškiai geltoną juostą su užrašu „STAGING – tik testiniai duomenys“, kai aplinkos kintamasis APP_ENV yra „staging“. Tokiu atveju pridėkite ir noindex meta žymę.

6 žingsnis. Sukurkite išleidimo rutiną

Staging padeda tik tada, kai jį naudojate kiekvieną kartą. Paprasta rutina:

1. Atlikite pakeitimą kūrimo aplinkoje ir patikrinkite peržiūroje.
2. Išleiskite jį į staging.
3. Peržiūrėkite pagrindinius srautus: registracija, prisijungimas, pagrindinė funkcija, mokėjimai, viskas, ko pakeitimas palietė.
4. Jei kas nors sugenda, ištaisykite ir vėl išleiskite į staging.
5. Publikuokite tą pačią versiją į produkciją.
6. Greitai patikrinkite produkciją – tuos pačius srautus, trumpai.

Užrašykite pagrindinius srautus kaip trumpą testų scenarijų. Žr. kaip ištestuoti programėlę prieš paleidimą, kas turėtų į jį įeiti.

7 žingsnis. Atsargiai keiskite duomenų bazę

Duomenų bazės struktūros pakeitimai – pridėti stulpelį, pervadinti lentelę – yra tai, kur staging atsipirka.

• Kiekvieną struktūros pakeitimą pirmiausia paleiskite staging.
• Patikrinkite, ar esami duomenys išliko, o ne tik tai, ar veikia naujos funkcijos.
• Prieš tą patį pakeitimą vykdydami produkcijoje, padarykite produkcijos atsarginę kopiją. Žr. kaip sukurti programėlės duomenų bazės atsarginę kopiją.
• Pirmenybę teikite pakeitimams, kurie pridedia, o ne pervadina ar ištrina, kad sena versija vis dar veiktų, jei reikėtų grįžti atgal.

Pavyzdiniai užklausimai

Paaiškinkite, kas nutiktų esamiems duomenims, jei šį duomenų bazės pakeitimą paleistume produkcijoje. Ar kas nors ištrinama ar pervadinama?

Visus aplinkai specifinius nustatymus – API URL, raktus, el. pašto siuntėją, pačios svetainės URL – paimkite iš aplinkos kintamųjų su tais pačiais pavadinimais staging ir produkcijoje. Surašykite juos.

Parašykite trumpą kontrolinį sąrašą, kokius srautus turėčiau patikrinti staging prieš kiekvieną išleidimą, remdamasis tuo, ką daro ši programėlė.

Dažniausios klaidos

• Bendra duomenų bazė. Pati žalingiausia klaida. Staging visada turi savo.
• Tikri raktai staging aplinkoje. Tikri mokėjimai, tikri el. laiškai tikriems klientams.
• Staging nukrypsta nuo produkcijos. Skirtingos versijos ar nustatymai reiškia, kad staging nebeaptinka problemų.
• Vieša, indeksuojama staging svetainė, kuri atsiranda paieškos rezultatuose šalia tikrosios.
• Praleidimas staging „mažiems“ pakeitimams. Maži pakeitimai taip pat sugadina dalykus.
• Testavimas netinkamame skirtuke. Matoma juosta tai išsprendžia.

Kontrolinis sąrašas

• Staging veikia tuo pačiu kodu, steku ir paslaugomis kaip produkcija.
• Staging turi savo duomenų bazę su testiniais ar nuvalytais duomenimis.
• Mokėjimai, el. paštas ir mokamos API staging aplinkoje naudoja testinius raktus.
• Kintamųjų pavadinimai sutampa tarp aplinkų; keičiasi tik reikšmės.
• Staging apsaugotas prisijungimu ar slaptažodžiu ir neindeksuojamas.
• Rodoma juosta, kai esate staging aplinkoje.
• Kiekvienas išleidimas pirmiausia eina į staging, su užrašytu srautų sąrašu tikrinimui.
• Duomenų bazės pakeitimai pirmiausia paleidžiami staging, o prieš išleidimą padaroma produkcijos atsarginė kopija.

Staging su Mythex

Mythex Publish suteikia vieną tiesioginį URL kiekvienai programėlei; atskiro staging perjungiklio nėra. Praktiškai turite dvi galimybes:

• Peržiūra kaip prieš išleidimą tikrinimas. Kiekvienas projektas veikia privačioje debesies darbo aplinkoje su tiesiogine peržiūra. /test leidžia agentui paklikinėti per ją kaip vartotojui, o Share nuoroda leidžia klientui ar komandos nariui peržiūrėti, neviešinant. Žr. Preview and Code. Daugeliui individualių projektų to pakanka.
• Antras projektas kaip staging. Pro plane eksportuokite projektą ir importuokite į naują projektą, suteikite jam savo duomenų bazę ir testinių raktų paslaptis bei publikuokite jį su savo slug. Prieš publikuodami produkcijos projektą, išleiskite į jį.

Bet kuriuo atveju prieš atlikdami bet kokį destruktyvų testą, paklauskite agento, kokią duomenų bazę naudoja peržiūra ir publikuota programėlė, o blogą pakeitimą atšaukite naudodami kontrolinius taškus. Plačiau apie programėlių perkėlimą į produkciją – kaip perkelti DI prototipą į produkciją.

Klausimai