Kas ir pārbaudes vide? Pārbaudiet pirms publicēšanas

Pārbaudes vide ir jūsu lietotnes privāta kopija, iestatīta pēc iespējas tuvāk tiešraides versijai, kur pārbaudāt izmaiņas, pirms tās redz reāli lietotāji. Tai ir sava datubāze, testa dati un testa API atslēgas, tāpēc salauzta funkcija vai slikta datu izmaiņa tajā neietekmē nevienu ārpus jūsu komandas. Kad izmaiņa tajā šķiet pareiza, to laiž ražošanā — tiešraides lietotnē, ko izmanto jūsu klienti.

Kāpēc pārbaudes vide ir svarīga, veidojot ar AI

Veidojot ar AI, izmaiņas notiek ātri. Varat pievienot funkciju, pārrakstīt lapu vai mainīt datu struktūru dažās minūtēs. Tas ir lieliski, līdz brīdim, kad izmaiņa, kas šķita kārtīga, klusi salauž norēķinu vai „nelielā tīrīšana” izdzēš klientu datu kolonnu.

Vieta, kur pārbaudīt izmaiņas, pirms tās tiek publicētas, palīdz jums:

• Pamanīt bojājumus, pirms to pamana klienti. Pēc katras būtiskas izmaiņas izmēģiniet reģistrācijas, maksājumu un atslēgu plūsmas.
• Testēt reālos apstākļos. Pārbaudes videi jādarbojas kā ražošanai — tas pats steks, līdzīga konfigurācija —, lai problēmas parādītos tur, nevis vēlāk.
• Aizsargāt reālos datus. Datubāzes izmaiņas, importi un masveida rediģēšana vispirms jāizmēģina uz testa datiem.
• Parādīt darbu procesā. Klients vai kolēģis var pārskatīt izmaiņu, neko nepublicējot publiski.

Ikdienas salīdzinājums

Domājiet par teātra ģenerālmēģinājumu.

• Izstrāde ir mēģinājumu telpa: aktieri mēģina tekstus, aptur, sāk no jauna, eksperimentē.
• Pārbaudes vide ir ģenerālmēģinājums: pilni kostīmi, īstā skatuve, īstās gaismas — viss tā, kā būs pirmizrādē, tikai bez maksājoša skatītāju pūļa.
• Ražošana ir pirmizrāde. Kļūdas notiek visu acu priekšā.

Vairums problēmu, kuras nevēlaties redzēt pirmizrādē, parādās ģenerālmēģinājumā: kostīmu maiņa, kas aizņem pārāk ilgi, nepareiza gaismas ieslēgšana. Tieši tāds ir pārbaudes vides uzdevums.

Trīs izplatītākās vides

Katra vide atšķiras galvenokārt ar savu konfigurāciju: ar kuru datubāzi tā savienojas, kuras atslēgas izmanto, kurā URL dzīvo. Tāpēc labas lietotnes šos iestatījumus nolasa no vides mainīgajiem un noslēpumiem, nevis tos ieraksta kodā. Tā pats kods var darboties katrā vidē ar atšķirīgiem iestatījumiem.

Praktisks piemērs: rezervāciju lietotnes atcelšanas noteikumu maiņa

Jums ir skaistumkopšanas salona rezervāciju lietotne ar maksājošiem klientiem. Vēlaties mainīt noteikumu, lai klienti var atcelt līdz 24 stundām iepriekš, nevis 48, un atmaksa notiek automātiski.

1. Izveidojiet izstrādē. Lūdziet AI veidotājam izmaiņu. Tas atjaunina atcelšanas loģiku un atmaksas izsaukumu uz jūsu maksājumu sniedzēju.

2. Laidiet pārbaudes videi. Pārbaudes vide darbina to pašu kodu, savienotu ar pārbaudes datubāzi ar testa rezervācijām un jūsu maksājumu sniedzēja testa režīma atslēgām.

3. Pārbaudiet reālās plūsmas. Jūs un kolēģis:

• rezervējat testa vizīti rītdienai un atceļat to 30 stundas iepriekš — atmaksai jānotiek;
• mēģināt atcelt 10 stundas iepriekš — tam jābūt noraidītam ar skaidru ziņojumu;
• pārbaudāt, ka atmaksa parādās maksājumu sniedzēja testa panelī;
• pārbaudāt, ka apstiprinājuma e-pasts runā par 24 stundām, nevis 48.

4. Atrodiet kļūdu. Pārbaudes vidē pamanāt, ka noteikums izmanto servera laika joslu, nevis salona, tāpēc atcelšanas robeža ir par stundu nepareiza. Labojat to un pārbaudāt vēlreiz.

5. Laidiet ražošanā. Tikai tagad izmaiņa nonāk pie reāliem klientiem — laika joslas kļūda jau ir noķerta.

Bez pārbaudes vides 4. solis būtu noticis ar reāla klienta atmaksu.

Galvenie termini

Biežākie nepareizi priekšstati

• „Pārbaudes vide var kopīgot ražošanas datubāzi.” Tas ir visbīstamākais saīsinājums. Tests, kas dzēš vai rediģē ierakstus, skartu reālus klientus. Dodiet pārbaudes videi savu datubāzi.
• „Ja tas darbojas pārbaudes vidē, tas nevar salūst ražošanā.” Pārbaude samazina risku, bet to neatceļ. Reāls trafiks, reāli dati un ārējie pakalpojumi joprojām var pārsteigt. Saglabājiet iespēju atgriezties.
• „Pārbaudes videi jābūt dārgai.” Tā var būt maza. Tai vajag tādu pašu uzbūvi kā ražošanai, nevis tādu pašu izmēru.
• „Izmantojiet reālas maksājumu atslēgas pārbaudes videi, lai būtu reālistiski.” Izmantojiet sniedzēja testa režīmu. Reālistiski nenozīmē reāla nauda.
• „Pārbaudes vide ir tikai lielām komandām.” Ideja — testēt drošā vietā — noder arī vienam cilvēkam. Ceremoniju līmenis var atbilst likmēm.
• „Pārbaudes videi jābūt publiskai, lai cilvēki to izmēģinātu.” Turiet to privātu vai aizsargātu un aizliedziet meklētājprogrammām to indeksēt, lai neviens to nejauc ar īsto lietotni.

Ko prasīt savam AI veidotājam

• „Padariet katru videi specifisku iestatījumu — datubāzi, API atslēgas, vietnes URL — par vides mainīgajiem.”
• „Pievienojiet sēklas skriptu, kas piepilda ne-ražošanas datubāzi ar reālistiskiem testa datiem.”
• „Izmantojiet maksājumu sniedzēja testa režīmu, līdz es teikšu, ka sākam.”
• „Pirms šīs izmaiņas laišanas uzskaitiet plūsmas, kuras man jātestē, un ko katrai no tām vajadzētu notikt.”
• „Vai šī izmaiņa ietekmēs esošos datus? Vispirms parādiet migrāciju.”
• „Pārliecinieties, ka ne-ražošanas vietnes kopijas nav indeksētas meklētājprogrammās.”

Pakāpeniskai uzstādīšanai skatiet kā iestatīt pārbaudes vidi. Kad izlaidumi kļūst bieži, automatizēt ceļu no koda līdz pārbaudei un ražošanai ir tieši tas, par ko ir CI/CD.

Testēšana pirms laišanas Mythex

Mythex nav atsevišķa pārslēdzēja „pārbaude pret ražošanu”; publicēšana dod vienu tiešraides publisku URL, un dokumentācija to saka skaidri (vairāku pakalpojumu lietotnes). Tā dod skaidru robežu starp veidošanu un tiešraidi:

• Priekšskatījums darbina jūsu lietotni privātā mākoņa smilškastē, kamēr veidojat. Izmaiņas parādās vispirms tur, nevis jūsu tiešraides lietotnē.
• Koplietošana izveido priekšskatījuma saites, lai klients vai kolēģis varētu pārskatīt darba procesā esošo versiju bez Mythex konta un bez jūsu publicēšanas. Saite rāda smilškastes pašreizējo stāvokli, ieskaitot izmaiņas veidošanas laikā, un jūs to varat dzēst jebkurā brīdī.
• Publicēšana saglabā projekta momentuzņēmumu un izvieto to. Līdz nākamajai publicēšanai tiešraides lietotne paliek tāda, kāda bija.
• Kontrolpunkti tiek saglabāti pēc katras veiksmīgas aģenta kārtas, lai varētu atgriezt projekta failus, ja izmaiņa noiet greizi.

Uztveriet Priekšskatījumu kā savu mēģinājumu: turiet maksājumu sniedzējus testa režīmā līdz laišanai un pirms katras publicēšanas izejiet cauri galvenajām plūsmām. Kad iesaistīti reāli klienti, pirms jebkā, kas raksta vai dzēš datus, pārbaudiet ar aģentu, kuru datubāzi un atslēgas izmanto jūsu Priekšskatījums. Ja vajag pilnīgi atsevišķu pārbaudes vidi ar savu datubāzi, lūdziet aģentam paskaidrot jūsu projekta iespējas vai — Pro plānā — eksportējiet projektu vai sinhronizējiet to ar GitHub un palaidiet to infrastruktūrā, ko kontrolējat jūs.

Jautājumi