Kā iestatīt pārbaudes vidi (staging) savai lietotnei

Lai iestatītu pārbaudes vidi, izvietojiet otru lietotnes kopiju savā privātajā URL, dodiet tai savu datubāzi un testa API atslēgas un padariet to pēc iespējas līdzīgu ražošanas iestatījumiem. Pēc tam katru būtisku izmaiņu vispirms izlaidiet pārbaudes vidē, izejiet cauri svarīgākajām plūsmām un publicējiet ražošanā tikai tad, kad pārbaudes vide izskatās pareizi.

Ja šī ideja jums ir jauna, kas ir pārbaudes vide izskaidro koncepciju. Šī rokasgrāmata ir praktiska iestatīšana cilvēkiem, kas veido ar AI rīkiem, nevis vada DevOps komandu.

Izstrāde, pārbaudes vide un ražošana

Vairumam mazu lietotņu vajag trīs vietas, pat ja pirmā ir tikai jūsu veidotāja priekšskatījums:

Pārbaudes vides mērķis ir uzvesties kā ražošanai — tas pats kods, tas pats steks, tāda pati veida konfigurācija —, bet kļūda tur neviens nesāp.

1. solis: nolemt, kam pārbaudes videi jāatbilst

Pārbaudes vide ir noderīga tikai tad, ja problēmas tur parādās pirms ražošanas. Atbilstībai:

• Tas pats kods, izlaists tādā pašā veidā.
• Tas pats steks un versijas — ietvars, izpildlaika vide, datubāzes veids.
• Tāda pati veida konfigurācija — tie paši vides mainīgo nosaukumi ar testa vērtībām.
• Tie paši pakalpojumi — ja ražošanā ir tīmekļa lietotne un API, pārbaudes vidē ir abi.

Tā var atšķirties pēc izmēra (mazāka mašīna ir pieņemama) un pēc datiem.

2. solis: izveidot kopiju

Vienkāršākā pieeja: tā paša projekta otra izvietošana citā URL, piemēram, staging.yourapp.com vai yourapp-staging.example.com.

Kā to darīt, atkarīgs no jūsu hostinga:

• Hostingi ar iebūvētām priekšskatījuma vai pārbaudes izvietošanām var izveidot vienu automātiski Git atzaram.
• Hostingi bez tā: izveidojiet otru lietotni vai projektu no tā paša koda un izvietojiet to atsevišķi.
• Kods Git: turiet staging vai main atzaru, kas izvietojas pārbaudes vidē, un izvietojiet ražošanā no izlaiduma. Skatiet kā lietot Git ar AI veidotu lietotni.

3. solis: dodiet pārbaudes videi savu datubāzi

Tas ir solis, kas jūs pasargā. Ja pārbaudes vide un ražošana koplieto datubāzi, tests, kas dzēš ierakstus, dzēš reālos ierakstus.

• Izveidojiet atsevišķu datubāzi pārbaudes videi.
• Piepildiet to ar sēklas datiem — reālistiskiem izdomātiem ierakstiem, ko AI var ģenerēt jums.
• Ja vajag ražošanas datu kopiju, vispirms noņemiet vai sajauciet vārdus, e-pastus un visu personisko.

Uzrakstiet sēklas skriptu, kas piepilda tukšu datubāzi ar reālistiskiem testa datiem: 20 klienti, 50 pasūtījumi dažādos stāvokļos un divi administratori. Izmantojiet acīmredzami izdomātus vārdus un example.com e-pasta adreses.

Pirms paļaujaties uz iestatījumu, apstipriniet, ar kuru datubāzi savienojas katra kopija. Jautājiet tieši:

Ar kuru datubāzi savienojas šī lietotne un no kurienes nāk šis iestatījums? Parādiet mainīgā nosaukumu, nevis paroli.

4. solis: izmantojiet testa atslēgas un atsevišķus iestatījumus

Visam, kas sazinās ar ārēju pakalpojumu, pārbaudes vidē jāizmanto testa akreditācijas dati:

• Maksājumi testa režīmā (piemēram, Stripe testa atslēgas), lai neviena reāla karte netiek noņemta.
• E-pasts sūtīts uz smilškasti vai tikai uz jūsu pašu adresi, lai klienti nekad nesaņem testa ziņojumu.
• AI un citi maksas API ar atsevišķu atslēgu un zemu tēriņu limitu.
• Webhook norādīti uz pārbaudes vides URL, nevis uz ražošanu.

Turpiniet lietot tos pašus mainīgo nosaukumus abās vidēs un mainiet tikai vērtības. Tādā veidā kods nav jāzina, kur tas darbojas. Lai uzzinātu vairāk, skatiet kā sargāt API atslēgas.

5. solis: turiet pārbaudes vidi privātu

Pārbaudes videi nevajadzētu būt publiskai:

• Ievietojiet to aiz pieteikšanās, paroles vai komandas e-pastu atļauto sarakstu.
• Aizliedziet meklētājprogrammām to indeksēt ar noindex meta tagu vai X-Robots-Tag galveni.
• Nesaistiet to ar savu publisko vietni.
• Padariet to atšķirīgu — krāsains „STAGING“ baneris novērš testēšanu nepareizā cilnē.

Pievienojiet spilgti dzeltenu banneri katras lapas augšdaļā ar tekstu „STAGING — tikai testa dati“, kad vides mainīgais APP_ENV ir „staging“. Šajā gadījumā pievienojiet arī noindex meta tagu.

6. solis: izveidojiet izlaišanas rutīnu

Pārbaudes vide palīdz tikai tad, ja to lietojat katru reizi. Vienkārša rutīna:

1. Veiciet izmaiņu izstrādē un pārbaudiet to priekšskatījumā.
2. Izlaidiet to pārbaudes videi.
3. Izejiet cauri galvenajām plūsmām: reģistrācija, pieteikšanās, galvenā funkcija, maksājumi, viss, ko izmaiņa skārusi.
4. Ja kaut kas salūst, salabojiet un izlaidiet pārbaudes videi vēlreiz.
5. Publicējiet to pašu versiju ražošanā.
6. Ātri pārbaudiet ražošanu — tās pašas plūsmas, īsi.

Uzrakstiet galvenās plūsmas kā īsu testa skriptu. Skatiet kā pārbaudīt lietotni pirms palaišanas, ko iekļaut.

7. solis: uzmanīgi apstrādājiet datubāzes izmaiņas

Izmaiņas datubāzes struktūrā — kolonnas pievienošana, tabulas pārdēvēšana — ir vieta, kur pārbaudes vide atmaksājas.

• Vispirms veiciet katru strukturālu izmaiņu pārbaudes videi.
• Pārbaudiet, vai esošie dati saglabājās, nevis tikai to, vai darbojas jaunās funkcijas.
• Veiciet ražošanas dublējumu pirms tās pašas izmaiņas palaišanas tur. Skatiet kā dublēt lietotnes datubāzi.
• Dodiet priekšroku izmaiņām, kas pievieno, nevis pārdēvē vai dzēš, lai vecā versija joprojām darbotos, ja atgriežaties atpakaļ.

Piemēru uzvednes

Paskaidro, kas notiktu ar esošajiem datiem, ja šo datubāzes izmaiņu palaistu ražošanā. Vai kaut kas tiek dzēsts vai pārdēvēts?

Padari visus videi specifiskos iestatījumus — API URL, atslēgas, e-pasta sūtītāju, vietnes pašas URL — no vides mainīgajiem ar tiem pašiem nosaukumiem pārbaudes videi un ražošanai. Uzskaiti tos.

Uzrakstiet īsu kontrolsarakstu ar plūsmām, ko vajadzētu pārbaudīt pārbaudes videi pirms katra izlaiduma, balstoties uz to, ko šī lietotne dara.

Biežākās kļūdas

• Koplietota datubāze. Visnopietnākā kļūda. Pārbaudes videi vienmēr jābūt savai.
• Īstas atslēgas pārbaudes videi. Reāli maksājumi, reāli e-pasti reāliem klientiem.
• Pārbaudes vide novirzās no ražošanas. Atšķirīgas versijas vai iestatījumi nozīmē, ka pārbaudes vide vairs neatklāj problēmas.
• Publiska, indeksēta pārbaudes vietne, kas parādās meklēšanas rezultātos līdzās jūsu īstajai.
• Pārbaudes izlaišana „mazām“ izmaiņām. Mazas izmaiņas arī salauž lietas.
• Testēšana nepareizā cilnē. Redzams baneris to novērš.

Kontrolsaraksts

• Pārbaudes vide izmanto to pašu kodu, steku un pakalpojumus kā ražošana.
• Pārbaudes videi ir sava datubāze ar testa vai sajauktiem datiem.
• Maksājumi, e-pasts un maksas API pārbaudes videi izmanto testa atslēgas.
• Mainīgo nosaukumi sakrīt visās vidēs; atšķiras tikai vērtības.
• Pārbaudes vide ir aiz pieteikšanās vai paroles un nav indeksēta.
• Baneris parāda, ka esat pārbaudes vidē.
• Katrs izlaidums vispirms iet uz pārbaudes vidi ar rakstisku pārbaudāmo plūsmu sarakstu.
• Datubāzes izmaiņas vispirms tiek veiktas pārbaudes vidē, ar ražošanas dublējumu pirms izlaišanas.

Pārbaudes vide Mythex

Mythex Publish dod vienu tiešraides URL katrai lietotnei; atsevišķa pārbaudes vides pārslēgšanas nav. Praksē jums ir divas iespējas:

• Priekšskatījums kā pirmsizlaišanas pārbaude. Katrs projekts darbojas privātā mākoņa darbvietā ar tiešraides Preview. /test liek aģentam noklikšķināt pa to kā lietotājam, un Share saite ļauj klientam vai komandas biedram pārskatīt priekšskatījumu bez publicēšanas. Skatiet Preview un Code. Daudziem vieniem projektiem tas ir pietiekami.
• Otrs projekts kā pārbaudes vide. Pro versijā eksportējiet projektu un importējiet to jaunā projektā, dodiet tam savu datubāzi un testa atslēgu noslēpumus un publicējiet to savā slug. Izlaidiet uz to, pirms publicējat ražošanas projektu.

Jebkurā gadījumā, pirms testējat kaut ko destruktīvu, jautājiet aģentam, kurā datubāzē darbojas priekšskatījums un publicētā lietotne, un izmantojiet kontrolpunktus, lai atgrieztu sliktas izmaiņas. Plašākai lietotnes palaišanai skatiet kā AI prototipu novest līdz ražošanai.

Jautājumi