Mikä on staging-ympäristö? Testaa ennen julkaisua

Staging-ympäristö on sovelluksesi yksityinen kopio, pystytetty mahdollisimman lähelle live-versiota, jossa testaat muutoksia ennen kuin oikeat käyttäjät näkevät ne. Sillä on oma tietokanta, testidata ja testi-API-avaimet, joten rikki mennyt ominaisuus tai huono datamuutos siellä ei vaikuta kehenkään tiimisi ulkopuolella. Kun muutos näyttää oikealta stagingissa, julkaiset sen tuotantoon — live-sovellukseen, jota asiakkaasi käyttävät.

Miksi staging on tärkeä, kun rakennat tekoälyllä

Tekoälyn kanssa muutokset tapahtuvat nopeasti. Voit lisätä ominaisuuden, kirjoittaa sivun uudelleen tai muuttaa datarakennetta minuuteissa. Nopeus on hienoa, kunnes muutos, joka näytti hyvältä, rikkoo kassan tai ”pieni siivous” poistaa asiakasdatan sarakkeen.

Paikka, jossa muutoksia tarkistetaan ennen julkaisua, auttaa sinua:

• Huomaamaan rikkoutumiset ennen asiakkaita. Kokeile rekisteröitymis-, maksu- ja muita keskeisiä kulkuja aina merkittävän muutoksen jälkeen.
• Testaamaan oikeissa olosuhteissa. Stagingin pitäisi käyttäytyä kuten tuotanto — sama pino, samankaltaiset asetukset — jotta ongelmat näkyvät siellä eikä myöhemmin.
• Suojelemaan oikeaa dataa. Tietokantamuutokset, tuonnit ja massamuokkaukset voi harjoitella ensin testidatalla.
• Näyttämään keskeneräisen työn. Asiakas tai tiimikaveri voi tarkastella muutosta näkymättä julkisesti.

Arkinen vertauskuva

Ajattele teatterin generaaliharjoitusta.

• Kehitys on harjoitussali: näyttelijät kokeilevat repliikkejä, pysähtyvät, aloittavat uudelleen ja kokeilevat.
• Staging on generaaliharjoitus: täydet puvut, oikea lava, oikeat valot — kaikki kuten ensi-iltana, mutta ilman maksavaa yleisöä.
• Tuotanto on ensi-ilta. Virheet tapahtuvat kaikkien nähden.

Useimmat ongelmat, joita et halua ensi-iltaan, tulevat esiin generaaliharjoituksessa: puvunvaihto kestää liian kauan, valon vaihto on väärin. Juuri siihen staging on tarkoitettu.

Kolme yleistä ympäristöä

Ympäristöt eroavat pääasiassa asetuksissaan: mihin tietokantaan ne yhdistyvät, mitä avaimia ne käyttävät ja mistä osoitteesta ne löytyvät. Siksi hyvät sovellukset lukevat nämä asetukset ympäristömuuttujista ja salaisuuksista eikä kovakoodaa niitä. Sama koodi voi silloin toimia kaikissa ympäristöissä eri asetuksilla.

Esimerkki: varaussovelluksen peruutussääntöjen muuttaminen

Pyörität kampaamon varaussovellusta, jolla on maksavia asiakkaita. Haluat muuttaa sääntöä niin, että asiakkaat voivat perua 24 tuntia etukäteen 48 tunnin sijaan, ja hyvitykset tehdään automaattisesti.

1. Rakenna kehityksessä. Pyydät tekoälyltä muutoksen. Se päivittää peruutuslogiikan ja hyvityskutsun maksupalveluntarjoajallesi.

2. Vie stagingiin. Staging ajaa samaa koodia, yhdistettynä stagingin tietokantaan, jossa on testivarauksia, ja maksupalveluntarjoajasi testitilan avaimiin.

3. Testaa oikeat kulut. Sinä ja kollega:

• varaatte testiajan huomiseksi ja peruutatte sen 30 tuntia ennen — hyvityksen pitäisi tulla;
• yritätte perua 10 tuntia ennen — se pitäisi hylätä selkeällä viestillä;
• tarkistatte, että hyvitys näkyy maksupalveluntarjoajan testidashboardissa;
• tarkistatte, että vahvistusviestissä lukee 24 tuntia, ei 48.

4. Löydä virhe. Stagingissa huomaat, että sääntö käyttää palvelimen aikavyöhykettä eikä salongin, joten katkaisuhetki on tunnin pielessä. Korjaat sen ja testaat uudelleen.

5. Julkaise tuotantoon. Vasta nyt muutos tavoittaa oikeat asiakkaat — aikavyöhykevirhe on jo löydetty.

Ilman stagingia kohta 4 olisi tapahtunut oikean asiakkaan hyvityksen kanssa.

Keskeiset termit

Yleisiä väärinkäsityksiä

• ”Staging voi jakaa tuotannon tietokannan.” Tämä on vaarallisin oikotie. Testi, joka poistaa tai muokkaa tietueita, osuisi oikeisiin asiakkaisiin. Anna stagingille oma tietokanta.
• ”Jos se toimii stagingissa, se ei voi hajota tuotannossa.” Staging vähentää riskiä, mutta ei poista sitä. Oikea liikenne, oikea data ja ulkoiset palvelut voivat yllättää. Pidä huolta mahdollisuudesta palauttaa edellinen versio.
• ”Stagingin pitää olla kallis.” Se voi olla pieni. Sen pitää vastata tuotannon rakennetta, ei sen kokoa.
• ”Käytä live-maksuavaimia stagingissa, jotta se on realistinen.” Käytä palveluntarjoajan testitilaa. Realistinen ei tarkoita oikeaa rahaa.
• ”Staging on vain suurille tiimeille.” Ajatus — testaa turvallisessa paikassa ensin — on hyödyllinen jopa yksin tekevälle. Muodollisuuden määrä voi skaalautua panosten mukaan.
• ”Stagingin pitäisi olla julkinen, jotta ihmiset voivat kokeilla sitä.” Pidä se yksityisenä tai suojattuna ja estä hakukoneita indeksoimasta sitä, ettei kukaan sekoita sitä oikeaan sovellukseen.

Mitä pyytää tekoälyrakentajalta

• ”Tee jokaisesta ympäristökohtaisesta asetuksesta — tietokannasta, API-avaimista ja sivuston osoitteesta — ympäristömuuttuja.”
• ”Lisää siemenskripti, joka täyttää ei-tuotantotietokannan realistisella testidatalla.”
• ”Käytä maksupalveluntarjoajan testitilaa, kunnes sanon julkaisevamme.”
• ”Ennen kuin tämä muutos menee live-tilaan, listaa kulut, jotka minun pitäisi testata, ja mitä niissä pitäisi tapahtua.”
• ”Vaikuttaako tämä muutos olemassa olevaan dataan? Näytä migraatio ensin.”
• ”Varmista, että ei-tuotantokopiot sivustosta eivät ole hakukoneiden indeksoimia.”

Vaiheittaiset ohjeet löydät kohdasta kuinka stagingympäristö pystytetään. Kun julkaisuja on paljon, koodin vieminen stagingin ja tuotannon kautta automaattisesti on CI/CD:n tehtävä.

Testaaminen ennen julkaisua Mythexissä

Mythexissä ei ole erillistä ”staging vs. tuotanto” -valintaa. Julkaisu antaa yhden live-julkisen URL-osoitteen, ja dokumentaatio sanoo tämän suoraan (monipalveluiset sovellukset). Se antaa kuitenkin selkeän rajan rakentamisen ja julkaisun välille:

• Esikatselu ajaa sovelluksesi yksityisessä pilvihiekkalaatikossa rakentamisen aikana. Muutokset näkyvät ensin siellä, ei live-sovelluksessasi.
• Jakaminen luo esikatselulinkkejä, joilla asiakas tai tiimikaveri voi tarkastella keskeneräistä työtä ilman Mythex-tiliä eikä sinun tarvitse julkaista. Linkki näyttää hiekkalaatikon juuri nyt, myös kesken rakentamisen tehdyt muutokset, ja voit poistaa linkin milloin tahansa.
• Julkaisu tallentaa projektin tilannekuvan ja julkaisee sen. Ennen seuraavaa julkaisua live-sovellus pysyy ennallaan.
• Tarkistuspisteet tallennetaan jokaisen onnistuneen agenttivuoron jälkeen, joten voit palauttaa projektitiedostot, jos muutos menee pieleen.

Käytä Esikatselua harjoitussalinasi: pidä maksupalveluntarjoajat testitilassa ennen lanseerausta ja käy keskeiset kulut läpi ennen jokaista julkaisua. Kun oikeat asiakkaat ovat mukana, kysy agentilta, mihin tietokantaan ja avaimiin esikatselusi yhdistyy, ennen kuin testaat mitään, mikä kirjoittaa tai poistaa dataa. Jos tarvitset täysin erillisen stagingin omalla tietokannalla, pyydä agenttia selittämään vaihtoehtosi projektillesi — tai Prossa vie projekti tai synkronoi se GitHubiin ja aja se infrastruktuurissa, jota hallitset itse.

Kysymykset