Näin viet tekoälyprototyypin tuotantoon

Tekoälyprototyypin viemiseksi tuotantoon kuromme umpeen kuilun ”toimii, kun kokeilen” ja ”toimii, kun muut käyttävät” välillä. Käytännössä se tarkoittaa viittä asiaa: testaa pääpolut joka kerta, kun muutat jotain, lukitse, kuka saa nähdä ja muuttaa mitä, varmista, että kuulet virheistä ennen kuin käyttäjät kertovat sinulle, varmuuskopioi data ja todista, että voit palauttaa sen, ja pidä sovellus riittävän nopeana puhelimella. Mikään tästä ei vaadi uudelleenkirjoitusta. Se on tarkistuslista, jonka käyt läpi saman tekoälyn kanssa, joka prototyypin rakensi.

Prototyyppi vs. tuotanto: mikä oikeasti muuttuu

Prototyypillä on yksi huolellinen käyttäjä: sinä. Tiedät, mitä nappeja painaa, kirjoitat järkevää syötettä, ja jos jokin hajoaa, kohautat olkapäitä ja pyydät tekoälyä korjaamaan sen. Tuotannossa käyttäjiä on monia, osa huolimattomia, osa uteliaita ja joskus joku vihamielinen. Koodin ei tarvitse muuttua ”yritystasoiseksi”; sen täytyy käsitellä tilanteet, joita prototyyppi ei koskaan kohtaa.

Loppu opas käy läpi jokaisen rivin.

Vaihe 1: Rajaa laajuus ja kirjaa pääpolut ylös

Ennen kuin kovennat mitään, päätä, mikä versio yksi on. Listaa kolmesta kuuteen polkua, jotka ovat tärkeimpiä, esimerkiksi ”rekisteröidy, luo projekti, kutsu tiimiläinen, maksa”. Nämä muuttuvat testiskriptiksi, valvonnan kohteiksi ja asioiksi, jotka tarkistat jokaisen muutoksen jälkeen.

Listalla olemattomat asiat joko karsitaan tai merkitään selvästi betaksi. Neljän polun luotettavaksi tekeminen on paljon helpompaa kuin neljätoista.

Vaihe 2: Testaa kuin vieras ja tee siitä toistettavaa

Tekoälyrakentajat osaavat tuottaa koodia, joka toimii onnellisella polulla. Tuotantoongelmat asuvat epäonnisilla poluilla. Testaa jokainen pääpolku seuraavilla:

• Huono syöte: pakolliset kentät tyhjinä, 5 000 merkin nimi, sähköposti ilman @-merkkiä, negatiivinen määrä, menneisyyden päivämäärä.
• Päivitykset ja takaisin-painike: lataa uudelleen kesken kassan; paina takaisin lomakkeen lähetyksen jälkeen. Luodaanko jotain kahdesti?
• Kaksi välilehteä, kaksi käyttäjää: kirjaudu kahdella eri tilillä ja yritä avata toisen käyttäjän sivuja vaihtamalla URL-osoitteen tunnusta.
• Hidas ja pieni: puhelimen kokoinen näyttö ja rajoitettu yhteys (selaimen kehitystyökalut voivat simuloida sitä).
• Tyhjät tilat: täysin uusi tili ilman dataa. Prototyypit on usein rakennettu näytedatalla, ja ilman sitä ne näyttävät rikkinäisiltä.

Sitten tee tarkistuksesta toistettava. Vähintäänkin pidä kirjallista listaa ja aja se ennen jokaista julkaisua. Parempi on pyytää tekoälyä kirjoittamaan automaattisia päästä päähän -testejä tärkeimmille poluille:

Lisää automaattiset päästä päähän -testit näille poluille: rekisteröityminen sähköpostilla, projektin luominen, toisen käyttäjän kutsuminen ja kassan läpikäynti Stripen testitilassa. Lisää myös testit, jotka varmistavat, ettei käyttäjä voi nähdä tai muokata toisen käyttäjän projektia vaihtamalla URL-osoitetta.

Testit, jotka todistavat, että käyttäjä ei voi tehdä jotain, ovat niitä, joita prototyypeiltä useimmin puuttuu.

Vaihe 3: Tietoturvan perusasiat, jotka prototyypit ohittavat

Tekoälyllä tehtyjen sovellusten tietoturvaongelmat eivät yleensä ole eksoottisia. Ne ovat puuttuvia tarkistuksia. Käy tämä lista läpi, ja katso laajempi tietoturvatarkistuslista tekoälyllä tehdyille sovelluksille:

• Valtuutus palvelimella. Napin piilottaminen ei ole turvallisuutta. Jokaisen pyynnön, joka lukee tai muuttaa dataa, on tarkistettava palvelimella, että kirjautunut käyttäjä saa tehdä sen. Jos sovelluksesi käyttää tietokantaa riviltasoisilla säännöillä, tarkista, että ne ovat päällä ja testattu.
• Salaisuudet pois selaimesta. Maksu-, sähköposti- tai tekoälypalveluiden API-avaimet kuuluvat palvelimen ympäristömuuttujiin, eivät etupään koodiin. Jos et ole varma, mitä tämä tarkoittaa, lue mitä ympäristömuuttujat ja salaisuudet ovat.
• Validointi palvelimella. Selaimen tarkistukset voi ohittaa, joten toista jokainen tärkeä tarkistus palvelimella.
• Kirjautuminen kunnolla. Käytä hyvin testattua autentikointikirjastoa tai -palvelua, älä omaa salasanojen tallennusta. Oppaamme kirjautumisen lisäämisestä sovellukseesi käy vaihtoehdot läpi.
• Pyyntörajoitukset kirjautumiseen, rekisteröitymiseen, salasanan palautukseen ja kaikkeen, mikä lähettää sähköpostia tai kutsuu maksullista rajapintaa.
• Ystävälliset virheilmoitukset. Käyttäjät näkevät ”jotain meni pieleen”; yksityiskohdat menevät lokeihin, eivät ruudulle.
• Vaihda vuotanut avain. Jos tuotantoavain on koskaan liitetty chatiin, committiin tai kuvakaappaukseen, vaihda se palveluntarjoajalla.

Yksi kehote, joka kattaa paljon kerralla:

Tarkista tämä sovellus tuotannon tietoturvan kannalta. Varmista, että jokainen API-reitti tarkistaa kirjautuneen käyttäjän omistavan tietueen, jota se lukee tai muuttaa, että salaisia avaimia ei lähetetä selaimelle, että syötteet validoidaan palvelimella ja että kirjautuminen ja salasanan palautus on pyyntörajoitettu. Luettele löydökset ennen kuin muutat mitään.

Listan pyytäminen ensin antaa sinun nähdä ongelmat ja päättää järjestyksen sen sijaan, että saisit yhden valtavan muutoksen.

Vaihe 4: Tiedä, kun jokin hajoaa: lokitus ja valvonta

Esikatselussa näet virheet heti, kun ne tapahtuvat. Tuotannossa sovelluksen pitää kertoa sinulle. Kolme kerrosta, halvimmasta hyödyllisimpään:

1. Palvelinlokit. Varmista, että virheet kirjataan riittävällä kontekstilla toistamiseen: mikä reitti, minkä käyttäjän ID (ei salasanaa tai korttitietoja), millainen syöte. Pyydä tekoälyä lisäämään jäsennelty lokitus, jos sovellus vain tulostaa konsoliin.
2. Virheiden seuranta. Palvelu, kuten Sentry tai vastaava, tallentaa etu- ja takapään poikkeukset, ryhmittelee ne ja lähettää sinulle sähköpostia. Pienelle sovellukselle näiden palveluiden ilmaiset tasot riittävät usein; tarkista nykyiset rajat niiden sivuilta.
3. Käytettävyystarkistukset. Ulkopuolinen palvelu, joka lataa kotisivusi ja yhden tärkeän API-reitin muutaman minuutin välein ja hälyttää, jos ne epäonnistuvat. Tämä tavoittaa ongelmat, jotka estävät sovellusta kirjaamasta mitään.

Lisää vielä yksi tapa: jokaisen julkaisun jälkeen avaa live-sovellus ja aja pääpolkujen tarkistuslista oikeassa URL-osoitteessa, ei vain esikatselussa.

Vaihe 5: Varmuuskopiot ja paluutie

Kahta eri asiaa pitää suojella, ja niitä on helppo sekoittaa.

• Koodi. Pidä projekti versionhallinnassa, jotta jokainen muutos voidaan perua. Monet tekoälyrakentajat tallentavat tiedostoistasi tarkistuspisteitä; synkronointi Git-repositorioon antaa kopion myös rakentajan ulkopuolelle.
• Data. Koodin palauttaminen ei palauta tietokantaa. Huono migraatio tai virheellinen poistonappi voi tuhota rivejä, joita mikään koodin tarkistuspiste ei tuo takaisin.

Datan osalta aseta säännöllinen varmuuskopiointi tallennettuna muualle kuin sovelluksen omaan isännöintiin. Postgres-tietokannalle yleinen tapa on ajastettu pg_dump erilliseen tallennustilaan, ja monet hallitut tietokantapalvelut tarjoavat automaattisia varmuuskopioita tai palautuksen tiettyyn hetkeen. Tee sitten vaihe, jonka useimmat jättävät väliin: palauta varmuuskopio erilliseen testitietokantaan ja tarkista, että data on siellä.

Pyydä tekoälyä myös tekemään tuhoavista toimista turvallisempia: vahvistusvaihe poistoille ja ”pehmeä poisto” (rivi merkitään poistetuksi eikä sitä poisteta) kaikelle, mitä käyttäjät saattavat haluta takaisin.

Vaihe 6: Suorituskyky, joka kestää puhelimella

Prototyypit tuntuvat nopeilta, koska olet ainoa käyttäjä ja data on pientä. Ennen julkaisua:

• Lataa oikean kokoista dataa. Pyydä tekoälyä täyttämään muutama tuhat riviä ja katso, mitkä sivut hidastuvat. Listat tarvitsevat yleensä sivutuksen, ja tietokanta tarvitsee yleensä indeksit sarakkeille, joilla suodatat ja lajittelet.
• Pienennä kuvat. Liian suuret kuvat ovat yleisin syy hitaaseen sivun latautumiseen. Pyydä kuvia, jotka on skaalattu ja pakattu, ja laiska lataus näkyvän alueen alapuolella.
• Mittaa. Aja Lighthouse Chromen kehitystyökaluissa live-URL-osoitteella mobiilitilassa. Googlen Core Web Vitals -mittarit ovat järkevä tavoite: Largest Contentful Paint alle 2,5 sekuntia, Interaction to Next Paint 200 ms tai vähemmän ja Cumulative Layout Shift 0,1 tai vähemmän.
• Varo ”heräämisviiveitä”. Isännöinti, joka nukkuu tyhjäkäynnillä, säästää rahaa, mutta tekee ensimmäisestä käynnistä hiljaisen jakson jälkeen hitaamman. Se on usein hyvä kauppa uudelle sovellukselle, kunhan tiedät sen tapahtuvan.

Projektisivu on hidas 5 000 rivillä. Lisää palvelinpuolen sivutus (25 per sivu), lisää tietokantaindeksit sarakkeille, joilla suodatamme ja lajittelemme, ja näytä lataustila, kun seuraava sivu latautuu.

Vaihe 7: Operatiiviset perusasiat

Muutama pieni asia erottaa harrastesovelluksen sovelluksesta, johon ihmiset luottavat:

• Oma verkkotunnus HTTPS:llä. Katso näin yhdistät oman verkkotunnuksen.
• Transaktioviestit vahvistetusta verkkotunnuksesta rekisteröitymisvahvistuksiin ja salasanan palautuksiin. Aihe on käsitelty kohdassa näin lähetät sähköpostia sovelluksestasi.
• Tietosuojaseloste ja ehdot, jotka kuvaavat, mitä oikeasti keräät. Älä kopioi vaatimustenmukaisuusväitteitä, joita et ole ansainnut.
• Tukireitti, vaikka se olisi valvottu sähköpostiosoite.
• Erilliset testi- ja tuotantoavaimet maksuille ja sähköpostille sekä selkeä merkintä siitä, mikä ympäristö käyttää mitäkin.

Vaihe 8: Siisti luovutus

Jossain vaiheessa joku muu työskentelee sovelluksen parissa: freelancer, uusi yhteisperustaja tai sinä kuuden kuukauden päästä. Helpota sitä:

• README, joka kertoo, miten sovellus ajetaan, mitä ympäristömuuttujia se tarvitsee (vain nimet, ei arvoja) ja miten se julkaistaan.
• Pääpolkujen tarkistuslista ja automaattiset testit.
• Lyhyt arkkitehtuurimuistio: etupää, takapää, tietokanta, kolmannen osapuolen palvelut ja missä kukin on isännöity.
• Käyttöoikeuslista: kuka on ylläpitäjä verkkotunnuksessa, isännöinnissä, tietokannassa, maksu- ja sähköpostitileillä. Pidä nämä tilit yrityssähköpostin alla, ei henkilökohtaisen.
• Koodi Gitissä, mieluiten synkronoituna repositorioon, jonka omistat. Jos saatat siirtää isännöintiä myöhemmin, lue näin viet tekoälyllä rakennetun sovelluksen ja isännöit sen itse.

Tekoäly voi laatia suurimman osan tästä puolestasi:

Kirjoita tälle projektille README kehittäjälle, joka ei ole koskaan nähnyt sitä: mitä sovellus tekee, teknologiapino, miten se ajetaan paikallisesti, jokainen ympäristömuuttuja, jonka se lukee (vain nimet ja tarkoitus), miten tietokannan skeema on järjestetty ja miten se julkaistaan.

Tuotantovalmiuden tarkistuslista

• Pääpolut kirjattu ja testattu, myös ”ei pääse toisen käyttäjän dataan”
• Palvelinpuolen valtuutus ja validointi jokaisella datareitillä
• Ei salaisia avaimia etupään koodissa; vuotaneet avaimet vaihdettu
• Pyyntörajoitukset kirjautumiseen ja kaikkeen, mikä maksaa rahaa
• Virheiden seuranta ja käytettävyyshälytykset postilaatikkoon, jonka luet
• Tietokannan varmuuskopiot isännöinnin ulkopuolella, yksi onnistunut testipalautus
• Sivutus ja indeksit tarkistettu realistisella datalla
• Oma verkkotunnus, vahvistettu lähetysdomain, tietosuojaseloste
• README ja käyttöoikeuslista seuraavalle henkilölle

Tekeminen Mythexillä

Jos rakensit prototyypin Mythexissä, useimmat näistä vaiheista ovat kehotteita samassa projektissa. Kirjoita /test, ja Mythex klikkaa läpi live-esikatselun kuten käyttäjä ja raportoi rikkoutuneet polut. Katso Sovellustestaus. Salaisuudet menevät projektin salaisuuksiin eikä chatiin. Jokainen onnistunut agenttivuoro tallentaa tiedostoistasi tarkistuspisteen, johon voit palata. Julkaisu antaa live-URL-osoitteen, ja isännöinti sekä tietokanta laskutetaan samasta krediittisaldosta (isännöinnin rajat selittää, miten sovellukset ja tietokannat nukkuvat ja herävät). Tarkistuspisteet kattavat tiedostot, eivät tietokantarivejä, joten suunnittele silti datan varmuuskopiot. Pro-tilauksella voit yhdistää oman verkkotunnuksen ja viedä koodin tai synkronoida sen omaan GitHub-repositorioosi luovutusta varten.

Kysymykset