Kaip DI prototipą paleisti į gamybą

Norėdami DI prototipą paleisti į gamybą, užpildykite tarpą tarp „veikia, kai bandau“ ir „veikia, kai ja naudojasi kiti žmonės“. Praktiškai tai reiškia penkis dalykus: išbandyti pagrindines eigas kiekvieną kartą, kai ką nors keičiate; apriboti, kas gali matyti ir keisti ką; užtikrinti, kad sužinotumėte apie klaidas anksčiau nei jūsų naudotojai; daryti atsargines duomenų kopijas ir įrodyti, kad galite jas atkurti; bei išlaikyti programėlę pakankamai greitą telefone. Nė vienas iš tų dalykų nereikalauja perrašymo – tai kontrolinis sąrašas, kurį įveikiate su tuo pačiu DI, kuris sukūrė prototipą.

Prototipas ir gamyba: kas iš tikrųjų keičiasi

Prototipas turi vieną atsargų naudotoją: jus. Žinote, kuriuos mygtukus spausti, įvedate protingą informaciją, o jei kas nors sugenda, pakraipote galvą ir prašote DI pataisyti. Gamyboje yra daug neatsargių naudotojų, kai kurie smalsūs, o kartais ir priešiškas. Kodas nebūtinai turi tapti „įmonės lygio“; jis turi tvarkyti situacijas, su kuriomis prototipas niekada nesusiduria.

Likusi šio vadovo dalis apžvelgia kiekvieną eilutę.

1 žingsnis: sustabdykite apimtį ir užrašykite pagrindines eigas

Prieš bet ką stiprindami, nuspręskite, kas yra pirmoji versija. Surašykite tris–šešias svarbiausias eigas – pavyzdžiui, „registracija, projekto sukūrimas, komandos nario pakvietimas, apmokėjimas“. Jos tampa jūsų testų scenarijumi, stebėjimo taikiniais ir tuo, ką tikrinate po kiekvieno pakeitimo.

Visa, kas nėra sąraše, arba nukerpama, arba aiškiai pažymima kaip beta. Keturias eigas padaryti patikimas yra kur kas lengviau nei keturiolika.

2 žingsnis: testuokite kaip svetimas, tada padarykite tai kartojamą

DI kūrėjai gerai kuria kodą, kuris veikia įprastu keliu. Gamybos problemos slypi neįprastuose keliuose. Testuokite kiekvieną pagrindinę eigą su:

• Blogais įvesties duomenimis: tušti privalomi laukai, 5 000 simbolių vardas, el. paštas be @, neigiamas kiekis, data praeityje.
• Atnaujinimais ir grįžimais: perkraukite puslapį per mokėjimą; paspauskite „atgal“ po formos pateikimo. Ar kas nors sukuriama dvigubai?
• Du skirtukai, du naudotojai: prisijunkite su dviem skirtingomis paskyromis ir pabandykite atidaryti kito puslapius, keisdami ID URL adrese.
• Lėta ir maža: ekranas telefono dydžio ir ribotas interneto ryšys (naršyklės kūrėjo įrankiai gali tai imituoti).
• Tuščios būsenos: visiškai nauja paskyra be duomenų. Prototipai dažnai kuriami su pavyzdiniais duomenimis ir be jų atrodo sugedę.

Tada padarykite patikrinimą kartojamą. Mažiausiai laikykite parašytą kontrolinį sąrašą ir vykdykite jį prieš kiekvieną leidimą. Dar geriau – paprašykite DI parašyti automatinius testus svarbiausioms eigoms:

Pridėkite automatinius sistemos galo į galą testus šioms eigoms: registracija el. paštu, projekto sukūrimas, antro naudotojo pakvietimas ir apmokėjimo užbaigimas Stripe testiniu režimu. Taip pat pridėkite testus, kurie patvirtina, kad naudotojas negali peržiūrėti ar redaguoti kito naudotojo projekto keisdamas URL.

Testai, įrodantys, kad naudotojas negali kažko padaryti, – tai, ko prototipams dažniausiai trūksta.

3 žingsnis: saugumo pagrindai, kurių prototipai praleidžia

Dauguma saugumo problemų DI sukurtose programėlėse nėra egzotiškos. Trūksta patikrų. Peržiūrėkite šį sąrašą ir žr. išsamesnį saugumo kontrolinį sąrašą DI sukurtoms programėlėms:

• Įgaliojimas serveryje. Mygtuko paslėpimas nėra saugumas. Kiekviena užklausa, kuri skaito ar keičia duomenis, serveryje turi patikrinti, ar prisijungęs naudotojas turi teisę tai daryti. Jei jūsų programėlė naudoja duomenų bazę su eilučių lygio taisyklėmis, patikrinkite, ar jos įjungtos ir išbandytos.
• Paslaptys ne naršyklėje. Mokėjimų, el. pašto ar DI teikėjų API raktai priklauso serverio pusės aplinkos kintamiesiems, niekada ne front-end kodui. Jei nesate tikri, ką tai reiškia, perskaitykite kas yra aplinkos kintamieji ir paslaptys.
• Patikra serveryje. Naršyklę galima apeiti, todėl bet kurią svarbią patikrą pakartokite serveryje.
• Prisijungimas įgyvendintas tinkamai. Naudokite gerai išbandytą autentifikacijos biblioteką ar paslaugą, o ne patys kurtą slaptažodžių saugojimą. Mūsų vadove kaip pridėti prisijungimą prie programėlės aprašytos galimybės.
• Užklausų ribojimas prisijungimui, registracijai, slaptažodžio atkūrimui ir viskam, kas siunčia el. laiškus ar kviečia mokamą API.
• Draugiški klaidų pranešimai. Naudotojai turėtų matyti „kažkas nepavyko“; detalės turi keliauti į žurnalus, o ne į ekraną.
• Pakeiskite viską, kas nutekėjo. Jei tikras raktas kada nors buvo įklijuotas į pokalbį, commit ar ekrano nuotrauką, pakeiskite jį teikėjo sistemoje.

Užklausa, apimanti daug dalykų vienu metu:

Peržiūrėkite šią programėlę gamybinio saugumo požiūriu. Patikrinkite, ar kiekvienas API maršrutas patvirtina, kad prisijungęs naudotojas yra įrašo, kurį skaito ar keičia, savininkas, ar slaptųjų raktų nesiunčiama naršyklei, ar įvestys tikrinamos serveryje ir ar prisijungimas bei slaptažodžio atkūrimas turi užklausų ribojimą. Prieš ką nors keisdami, pirmiausia pateikite rastų problemų sąrašą.

Pirmiausia paprašius sąrašo galite matyti problemas ir nuspręsti eiliškumą, o ne gauti vieną milžinišką pakeitimą.

4 žingsnis: žinokite, kada kas nors sugenda – žurnalai ir stebėjimas

Peržiūroje klaidas matote, kai jos įvyksta. Gamyboje programėlė turi jums pranešti. Trys sluoksniai, nuo pigiausio iki naudingiausio:

1. Serverio žurnalai. Įsitikinkite, kad klaidos įrašomos su pakankamu kontekstu, kad jas būtų galima atkurti: koks maršrutas, kurio naudotojo ID (ne slaptažodis ar kortelė), kokia įvesties forma. Jei programėlė tik spausdina į konsolę, paprašykite DI įdiegti struktūrizuotą žurnalų rašymą.
2. Klaidų sekimas. Paslauga, pavyzdžiui, Sentry ar panašus įrankis, fiksuoja front-end ir back-end išimtis, jas grupuoja ir siunčia jums el. laišką. Mažai programėlei dažnai pakanka nemokamų šių paslaugų planų; dabartinius limitus patikrinkite jų svetainėse.
3. Veikimo laiko patikros. Išorinė paslauga, kuri kas kelias minutes įkelia jūsų pagrindinį puslapį ir vieną svarbų API maršrutą ir įspėja, jei jie nepavyksta. Tai pagauna problemas, dėl kurių programėlė apskritai nebeįrašo žurnalų.

Pridėkite dar vieną įprotį: po kiekvieno leidimo atidarykite gyvą programėlę ir atlikite pagrindinių eigų kontrolinį sąrašą tikru URL, o ne tik peržiūroje.

5 žingsnis: atsarginės kopijos ir kelias atgal

Reikia apsaugoti du skirtingus dalykus, ir juos lengva supainioti.

• Kodas. Laikykite projektą versijų kontrolėje, kad bet koks pakeitimas būtų atšaukiamas. Daugelis DI kūrėjų saugo failų kontrolinius taškus; sinchronizavimas su Git saugykla suteikia kopiją ir už kūrėjo ribų.
• Duomenys. Kodo atšaukimas neatšaukia duomenų bazės. Blogas migravimas ar klaidingas trynimo mygtukas gali sunaikinti eilutes, kurių joks kodo kontrolinis taškas negrąžins.

Duomenims nustatykite reguliarias atsargines kopijas, saugomas ne programėlės talpinimo vietoje – Postgres duomenų bazei įprasta planuota pg_dump kopija į atskirą saugyklą, o daugelis valdomų duomenų bazių teikėjų siūlo automatines kopijas ar atkūrimą iki tam tikro momento. Tada atlikite žingsnį, kurį dauguma praleidžia: atkurkite kopiją į bandomąją duomenų bazę ir patikrinkite, ar duomenys ten.

Taip pat paprašykite DI padaryti destruktyvius veiksmus saugesnius: patvirtinimo žingsnį trynimams ir „švelnųjį trynimą“ (eilutes pažymėti kaip ištrintas, o ne jas pašalinti) visam, ką naudotojai galbūt norės atkurti.

6 žingsnis: našumas, kuris išlaikomas telefone

Prototipai atrodo greiti, nes esate vienintelis naudotojas ir duomenų yra mažai. Prieš paleidimą:

• Įkelkite realaus dydžio duomenis. Paprašykite DI įrašyti keletą tūkstančių eilučių ir pažiūrėti, kurie puslapiai sulėtėja. Sąrašams paprastai reikia puslapiavimo, o duomenų bazei – indeksų stulpeliams, pagal kuriuos filtruojate ir rikiuojate.
• Sumažinkite paveikslėlius. Per dideli paveikslėliai – dažniausia priežastis, kodėl puslapis lėtai kraunasi. Paprašykite pakeisto dydžio, suspausto vaizdo ir atidėto įkėlimo žemiau sulankstymo linijos.
• Matuokite. Paleiskite Lighthouse Chrome kūrėjo įrankiuose gyvame URL mobiliajame režime. Google Core Web Vitals yra protingas tikslas: Largest Contentful Paint iki 2,5 sekundės, Interaction to Next Paint 200 ms ar mažiau ir Cumulative Layout Shift 0,1 ar mažiau.
• Stebėkite „prabudimo“ vėlavimus. Talpinimas, kuris miega, kai bejėgis, taupo pinigus, bet pirmas apsilankymas po ramaus laikotarpio tampa lėtesnis. Naujai programėlei tai dažnai priimtinas kompromisas; žinokite, kad taip vyksta.

Projektų puslapis lėtas su 5 000 eilučių. Pridėkite serverio pusės puslapiavimą (25 vienam puslapyje), pridėkite duomenų bazės indeksus stulpeliams, pagal kuriuos filtruojame ir rikiuojame, ir rodykite įkėlimo būseną, kol kraunamas kitas puslapis.

7 žingsnis: operaciniai pagrindai

Kelios mažos detalės skiria mėgėjišką programėlę nuo tokios, kuriai žmonės pasitiki:

• Individualus domenas su HTTPS. Žr. kaip prijungti individualų domeną.
• Transakcinis el. paštas iš patvirtinto domeno registracijos patvirtinimams ir slaptažodžių atkūrimui – aptarta kaip siųsti el. laiškus iš savo programėlės.
• Privatumo politika ir sąlygos, aprašantys, ką iš tikrųjų renkate. Nekopijuokite atitikties teiginių, kurių dar nepelnėte.
• Palaikymo kanalas – net stebimas el. pašto adresas.
• Atskiri testiniai ir tikri raktai mokėjimams ir el. paštui bei aiškus užrašas, kuri aplinka naudoja kurį.

8 žingsnis: tvarkingas perdavimas

Anksčiau ar vėliau programėlėje dirbs kitas žmogus: laisvai samdomas programuotojas, naujas bendraįkūrėjas ar jūs po šešių mėnesių. Tai palengvinkite:

• README, kuriame nurodyta, kaip ją paleisti, kokių aplinkos kintamųjų reikia (tik pavadinimai, niekada reikšmės) ir kaip ją diegti.
• Pagrindinių eigų kontrolinis sąrašas ir automatiniai testai.
• Trumpa architektūros pastaba: front-end, back-end, duomenų bazė, trečiųjų šalių paslaugos ir kur kiekviena talpinama.
• Prieigos sąrašas: kas turi administratoriaus prieigą prie domeno, talpinimo, duomenų bazės, mokėjimų ir el. pašto paskyrų. Šias paskyras laikykite po verslo el. paštu, o ne asmeniniu.
• Kodas Git, idealiu atveju sinchronizuotas su jums priklausančia saugykla. Jei vėliau galbūt keisite talpinimą, perskaitykite kaip eksportuoti ir talpinti DI sukurtą programėlę pačiam.

DI gali parengti didžiąją dalį to už jus:

Parašykite šio projekto README kūrėjui, kuris jo niekada nematė: ką daro programėlė, technologijų rinkinį, kaip ją paleisti lokaliai, kiekvieną aplinkos kintamąjį, kurį ji nuskaito (tik pavadinimai ir paskirtis), kaip organizuota duomenų bazės schema ir kaip ją diegti.

Pasiruošimo gamybai kontrolinis sąrašas

• Pagrindinės eigos užrašytos ir išbandytos, įskaitant „negali pasiekti kito naudotojo duomenų“
• Įgaliojimo ir patikros serveryje kiekviename duomenų maršrute
• Jokių paslaptių raktų front-end kode; pakeisti nutekėję raktai
• Užklausų ribojimas autentifikacijai ir viskam, kas kainuoja pinigus
• Klaidų sekimas ir veikimo laiko įspėjimai, nukreipti į el. pašto dėžutę, kurią skaitote
• Duomenų bazės atsarginės kopijos laikomos ne programėlės talpinimo vietoje, su bent vienu sėkmingu bandomuoju atkūrimu
• Puslapiavimas ir indeksai patikrinti su realistiškais duomenimis
• Individualus domenas, patvirtintas siuntimo domenas, privatumo politika
• README ir prieigos sąrašas tam, kas ateis po jūsų

Darbas su Mythex

Jei prototipą kūrėte Mythex, dauguma šių žingsnių yra užklausos tame pačiame projekte. Įveskite /test, ir Mythex gyvoje peržiūroje paspaudinės kaip naudotojas ir praneš apie sugedusias eigas – žr. Programėlės testavimas. Raktai įvedami į projekto paslaptis, o ne į pokalbį; kiekvienas sėkmingas agento ciklas išsaugo jūsų failų kontrolinį tašką, prie kurio galite grįžti; publikavimas suteikia gyvą URL, o talpinimas ir duomenų bazė apmokami iš to paties kreditų balanso (talpinimo limitai paaiškina, kaip programėlės ir duomenų bazės miega ir pabunda). Kontroliniai taškai apima failus, o ne duomenų bazės eilutes, todėl vis tiek planuokite duomenų atsargines kopijas. Pro plane galite prijungti individualų domeną ir eksportuoti kodą arba sinchronizuoti jį su savo GitHub saugykla perdavimui kitam.

Klausimai