Näin pystytät sovelluksellesi staging-ympäristön

Staging-ympäristön pystyttämiseksi julkaise sovelluksesi toinen kopio omaan yksityiseen osoitteeseensa, anna sille oma tietokanta ja testi-API-avaimet ja tee siitä mahdollisimman lähellä tuotantoa vastaava. Julkaise sen jälkeen jokainen merkittävä muutos ensin stagingiin, käy läpi tärkeimmät kulut ja julkaise tuotantoon vasta, kun staging näyttää oikealta.

Jos idea on sinulle uusi, mikä staging-ympäristö on selittää käsitteen. Tämä opas on käytännön pystytys ihmisille, jotka rakentavat tekoälytyökaluilla eivätkä pyöritä DevOps-tiimiä.

Kehitys, staging ja tuotanto

Pienissä sovelluksissa tarvitaan yleensä kolme paikkaa, vaikka ensimmäinen olisi vain rakentajasi esikatselu:

Stagingin tarkoitus on, että se käyttäytyy kuten tuotanto — sama koodi, sama pino, samanlaiset asetukset — mutta virhe siellä ei haittaa ketään.

Vaihe 1: Päätä, mitä stagingin pitää vastata

Staging on hyödyllinen vain, jos ongelmat näkyvät siellä ennen kuin ne näkyvät tuotannossa. Vastaa seuraavien osalta:

• Sama koodi, julkaistuna samalla tavalla.
• Sama pino ja versiot — framework, ajoympäristö, tietokantatyyppi.
• Samanlainen konfiguraatio — samat ympäristömuuttujien nimet testiarvoilla.
• Samat palvelut — jos tuotannossa on web-sovellus ja API, stagingissa on molemmat.

Koko ja data voivat erota (pienempi kone käy hyvin).

Vaihe 2: Luo kopio

Yksinkertaisin tapa: toinen julkaisu samasta projektista eri osoitteessa, kuten staging.yourapp.com tai yourapp-staging.example.com.

Tapa riippuu hostingistäsi:

• Hostingit, joissa on sisäänrakennetut esikatselu- tai staging-julkaisut, voivat luoda sellaisen automaattisesti Git-haaralle.
• Hostingit ilman sitä: luo toinen sovellus tai projekti samasta koodista ja julkaise se erikseen.
• Koodi Gitissä: pidä staging- tai main-haara, joka julkaisee stagingiin, ja julkaise tuotantoon julkaisusta. Katso miten käytät Giteä tekoälyllä rakennetussa sovelluksessa.

Vaihe 3: Anna stagingille oma tietokanta

Tämä vaihe suojaa sinua. Jos staging ja tuotanto jakavat tietokannan, testi, joka poistaa tietueita, poistaa oikeita tietueita.

• Luo stagingille erillinen tietokanta.
• Täytä se siemendatalla — realistisilla keksityillä tietueilla, jotka tekoäly voi luoda sinulle.
• Jos tarvitset kopion tuotantodatasta, poista tai sekoita nimet, sähköpostit ja kaikki henkilökohtainen ensin.

Kirjoita siemenskripti, joka täyttää tyhjän tietokannan realistisella testidatalla: 20 asiakasta, 50 tilausta eri tiloissa ja kaksi ylläpitäjää. Käytä selvästi keksittyjä nimiä ja example.com-sähköpostiosoitteita.

Ennen kuin luotat järjestelyyn, varmista, mihin tietokantaan kumpikin kopio yhdistyy. Kysy suoraan:

Mihin tietokantaan tämä sovellus yhdistää, ja mistä se asetus tulee? Näytä muuttujan nimi, älä salasanaa.

Vaihe 4: Käytä testiavaimia ja erillisiä asetuksia

Kaiken, mikä puhuu ulkopuolisen palvelun kanssa, pitää stagingissa käyttää testi-tunnuksia:

• Maksut testitilassa (esimerkiksi Stripen testiavaimet), jotta oikeaa korttia ei veloiteta.
• Sähköposti lähetettynä hiekkalaatikkoon tai vain omaan osoitteeseesi, jotta asiakkaat eivät koskaan saa testiviestiä.
• Tekoäly ja muut maksulliset rajapinnat erillisellä avaimella ja matalalla kulutusrajalla.
• Webhookit osoittamaan stagingin osoitteeseen, ei tuotantoon.

Pidä ympäristömuuttujien nimet samoina molemmissa ympäristöissä ja vaihda vain arvot. Silloin koodin ei tarvitse tietää, missä se ajetaan. Lisää aiheesta: miten pidät API-avaimet turvassa.

Vaihe 5: Pidä staging yksityisenä

Stagingin ei pidä olla julkinen:

• Laita se kirjautumisen, salasanan tai sähköpostilistan taakse.
• Estä hakukoneita indeksoimasta sitä noindex-metatagilla tai X-Robots-Tag-otsakkeella.
• Älä linkitä siihen julkiselta sivustoltasi.
• Tee siitä näköisesti erilainen — värillinen "STAGING"-banneri estää testaamisen väärässä välilehdessä.

Lisää jokaisen sivun yläosaan kirkkaankeltainen banneri, jossa lukee "STAGING — vain testidata", kun APP_ENV-ympäristömuuttuja on "staging". Lisää tässä tapauksessa myös noindex-metatagi.

Vaihe 6: Tee julkaisurutiini

Stagingista on hyötyä vain, jos käytät sitä joka kerta. Yksinkertainen rutiini:

1. Tee muutos kehityksessä ja tarkista se esikatselussa.
2. Julkaise se stagingiin.
3. Käy läpi tärkeimmät kulut: rekisteröityminen, kirjautuminen, pääominaisuus, maksut, kaikki mihin muutos koski.
4. Jos jokin hajoaa, korjaa ja julkaise uudelleen stagingiin.
5. Julkaise sama versio tuotantoon.
6. Tarkista tuotanto nopeasti — samat kulut, lyhyesti.

Kirjoita tärkeimmät kulut ylös lyhyeksi testiskriptiksi. Katso miten testaat sovelluksesi ennen lanseerausta siitä, mitä kannattaa sisällyttää.

Vaihe 7: Käsittele tietokantamuutokset huolellisesti

Tietokannan rakenteen muutokset — sarakkeen lisääminen, taulun uudelleennimeäminen — ovat kohta, jossa staging todella ansaitsee paikkansa.

• Aja jokainen rakenteellinen muutos ensin stagingissa.
• Tarkista, että olemassa oleva data säilyi, ei vain se, että uudet ominaisuudet toimivat.
• Ota tuotannosta varmuuskopio ennen saman muutoksen ajamista siellä. Katso miten varmuuskopioit sovelluksesi tietokannan.
• Suosi muutoksia, jotka lisäävät eivätkä nimeä uudelleen tai poista, jotta vanha versio toimii yhä, jos palaat takaisin.

Esimerkkikehotteita

Selitä, mitä tapahtuisi olemassa olevalle datalle, jos ajaisimme tämän tietokantamuutoksen tuotannossa. Poistetaanko tai nimetäänkö jotain uudelleen?

Tee kaikista ympäristökohtaisista asetuksista — API-osoitteista, avaimista, sähköpostin lähettäjästä ja sivuston omasta osoitteesta — ympäristömuuttujia, joilla on samat nimet stagingissa ja tuotannossa. Listaa ne.

Kirjoita lyhyt tarkistuslista kulkuista, jotka minun pitää testata stagingissa ennen jokaista julkaisua, tämän sovelluksen toiminnan perusteella.

Yleisiä virheitä

• Jaettu tietokanta. Kaikkein vahingollisin virhe. Stagingilla on aina oma.
• Live-avaimet stagingissa. Oikeita veloituksia, oikeita sähköposteja oikeille asiakkaille.
• Staging ajautuu tuotannosta. Eri versiot tai asetukset tarkoittavat, ettei staging enää löydä ongelmia.
• Julkinen, indeksoitu staging-sivusto, joka näkyy hakutuloksissa oikean sivustosi vieressä.
• Stagingin ohittaminen "pienissä" muutoksissa. Pienet muutokset rikkovat asioita myös.
• Testaaminen väärässä välilehdessä. Näkyvä banneri korjaa sen.

Tarkistuslista

• Staging ajaa samaa koodia, pinoa ja palveluita kuin tuotanto.
• Stagingilla on oma tietokanta testi- tai siivotulla datalla.
• Maksut, sähköposti ja maksulliset rajapinnat käyttävät stagingissa testiavaimia.
• Muuttujien nimet täsmäävät ympäristöjen välillä; vain arvot eroavat.
• Staging on kirjautumisen tai salasanan takana eikä indeksoitu.
• Banneri näkyy, kun olet stagingissa.
• Jokainen julkaisu menee ensin stagingiin kirjallisen tarkistettavien kulkujen listan kanssa.
• Tietokantamuutokset ajetaan ensin stagingissa, ja tuotannosta otetaan varmuuskopio ennen julkaisua.

Staging Mythexillä

Mythexin Publish antaa sinulle yhden live-osoitteen per sovellus; siinä ei ole erillistä staging-kytkintä. Käytännössä sinulla on kaksi vaihtoehtoa:

• Esikatselu julkaisua edeltävänä tarkistuksena. Jokainen projekti toimii yksityisessä pilvityötilassa live-esikatselulla. /test saa agentin klikkaamaan sen läpi kuin käyttäjä, ja Jaa-linkillä asiakas tai tiimiläinen voi tarkistaa esikatselun julkaisematta. Katso Esikatselu ja koodi. Tämä riittää monille yksin tehdyille projekteille.
• Toinen projekti stagingina. Pro-tasolla vie projekti, tuo se uuteen projektiin, anna sille oma tietokanta ja testiavainsalaisuudet ja julkaise se omalla slugilla. Julkaise siihen ennen tuotantoprojektin julkaisemista.

Molemmissa tapauksissa kysy agentilta, mitä tietokantaa esikatselu ja julkaistu sovellus käyttävät ennen kuin testaat mitään tuhoavaa, ja käytä tarkistuspisteitä palataksesi huonosta muutoksesta. Laajemmin sovelluksen julkaisemisesta käyttöön katso miten viet tekoälyprototyypin tuotantoon.

Kysymykset