Mennyibe kerülnek valójában a preview környezetek?

A preview környezetek bevezetése az egyik legnagyobb hatású fejlesztés, amit egy csapat elindíthat. A reviewer egy linkre kattintva használhatja a módosítást ahelyett, hogy diffeket olvasna és elképzelné az eredményt. A designhibák még a merge előtt kiderülnek. A QA többé nem külön fázis.

Ugyanakkor ezek azok a költségtételek, amelyek a legnagyobb eséllyel észrevétlenül megháromszorozzák a számládat. Ennek oka egy olyan egyszerű számtan, amit senki nem végez el abban a pillanatban, amikor bekapcsolja ezt a funkciót.

A számtan

A preview környezet költsége a nyitott pull requestek számával nő, nem a csapat létszámával vagy a merge-ek számával.

Egy négyfős, egészséges review-kultúrával rendelkező csapatnak bármikor lehet öt–nyolc nyitott PR-ja. Ha mindegyik a stack teljes másolatát provisionálja, akkor a production mellett öt–nyolc production-másolatot futtatsz. Egy havi 30 dollárba kerülő stack így már 180–270 dollárba kerül, és ez sehol nem jelent meg senki becslésében, mert a becslés egyetlen környezetről szólt.

Ráadásul a nyitott PR-ek éppen azokban az időszakokban szaporodnak meg, amikor a legkevésbé engedheted meg magadnak a meglepetéseket: release előtt, egy refaktorálás közben, vagy amikor valaki szabadságon van, és az ága három hétig nyitva marad.

Hová megy valójában a pénz?

A preview minden része másképp terheli a költségvetést. Ha tudod, melyik mennyibe kerül, a kiadás kontrollálhatóvá válik.

Application containerök — mérsékelt költség, és megéri. Ez az a rész, amelyre valóban szükséged van. Jól skálázható lefelé, mert egy preview-nak nincs szüksége a production memóriaigényére.

Adatbázisok — a drága rész. Preview-nként külön adatbázist fenntartani a legnagyobb költségtényező, és általában erre van a legkevésbé szükség. A legtöbb review-hoz nem izolált adatbázis kell, hanem egy adatbázis hihető adatokkal.

Build percek — láthatatlanok és összeadódnak. Minden, nyitott PR-be feltolt módosítás új buildet indít. Egy két hét alatt negyven commitot tartalmazó branch negyvenszer buildel. Ez valódi kiadás, amely soha nem jelenik meg futó erőforrásként, ezért a mentális költségellenőrzésből is teljesen kimarad.

Egress — preview-nként kicsi, összesítve jelentős. A preview URL-eket felfedezik és feltérképezik a crawlerek. Ha egy crawler nyolc preview környezetből tölti le az assetjeidet, nyolcszor annyi munkát végez, mint production esetén, és mindezt te fizeted.

Négy módszer a költségek csökkentésére az érték megőrzése mellett

Oszd meg az adatbázist

A módosítások többségénél a preview-k megoszthatnak egy reprezentatív adatokkal feltöltött adatbázist. Külön adatbázist csak azokhoz a PR-ekhez használj, amelyeknek tényleg szükségük van rá — migrációkhoz, sémamódosításokhoz és minden destruktív változtatáshoz.

A gyakorlatban működő szabály: csak akkor használj izolált adatbázist, ha a PR érinti a sémát. Minden más megosztva működik.

Méretezd kisebbre a preview-t

Egyetlen reviewert kiszolgáló preview-nak nincs szüksége a production erőforrásaira. A memória felére és a CPU töredékére csökkentett erőforrások általában észrevehetetlenek a reviewert használó személy számára, miközben érdemben olcsóbbak.

dockup resources my-project/my-api --memory 512 --cpu 0.5

Járasd le őket

Ez az egyetlen legnagyobb hatású módosítás. Egy preview nem maradhat tovább életben, mint a hozzá tartozó pull request.

A merge vagy lezárás utáni automatikus teardown alapkövetelmény. Ami azonban gyakran kifog a csapatokon, az elhagyott PR — egy branch, amelyet valaki megnyitott, aztán más feladatra állították át, és soha nem zárták le. Ezek a környezetek hónapokig futnak.

Érdemes maximális élettartamot is beállítani: például minden tizennégy napnál régebbi preview törlődjön a PR állapotától függetlenül. Ha valakinek újra szüksége van rá, egyetlen paranccsal visszaállítható.

Tartsd távol őket a keresőktől

A preview URL-ek bekerülnek az indexbe. Ez két okból is rossz — duplikált tartalom versenyez a production oldaladdal, és olyan környezeteken generálódik crawlerforgalom, amelyeket senki sem használ, de te fizetsz érte.

dockup noindex my-project/my-api --on

A Dockupban a PR preview-k szolgáltatásonként kezelhetők, és explicit módon engedélyezhetők vagy tilthatók, ahelyett hogy egy örökölt globális beállítás szabályozná őket:

dockup pr-preview my-project/my-api --on
dockup preview list my-project/my-api --json
dockup preview delete 128 my-project/my-api

A listázást hagyják ki a csapatok a leggyakrabban, aztán később megbánják. Azok a környezetek, amelyeket nem tudsz felsorolni, olyan környezetek, amelyekért úgy fizetsz, hogy nem is tudsz róluk.

Az audit, amit érdemes havonta egyszer elvégezni

Három kérdés, öt perc:

1. Hány preview fut? Hasonlítsd ezt össze a ténylegesen nyitott PR-ek számával.
2. Milyen régi a legrégebbi? Ami két hétnél régebbi, az szinte biztosan elhagyott.
3. Melyiknek van saját adatbázisa? Ami nem sémamódosítás, annak valószínűleg nincs szüksége saját adatbázisra.

A legtöbb csapat legalább egy olyan környezetet talál, amely egy hónapokkal korábban merge-ölt PR-hez tartozik, még mindig fut, és továbbra is számlázódik.

Hogyan szerezd meg az előnyöket meglepetések nélkül?

Mindez nem érv a preview környezetek ellen. Amellett szól, hogy checkbox helyett életciklussal rendelkező infrastruktúraként kezeld őket.

A jól teljesítő csapatok három dolgot csinálnak: kisebbre skálázzák a preview-kat, lejáratják őket, és mindent megosztanak, amit biztonságosan meg lehet osztani. Így a teljes preview-infrastruktúra költsége általában egyetlen production szolgáltatás költsége alatt marad — ezen az áron pedig már egyértelműen megéri.

Azok a csapatok lepődnek meg a számlán, amelyek egyszer, helyesen bekapcsolták a funkciót, majd soha többé nem nézték meg a listát.

Gyakran ismételt kérdések

A preview környezetek ugyanannyiba kerülnek, mint a production? Környezetenként igen, ha ugyanúgy provisionálod őket. Kisebbre skálázva és megosztott adatbázissal egy preview jellemzően a production költségének töredékébe kerül.

Minden preview-hoz saját adatbázist kell használni? Csak akkor, ha a módosítás érinti a sémát. Egy közös, előre feltöltött adatbázis a legtöbb review-hoz elegendő, és megszünteti a legnagyobb költségtényezőt.

Mi történik a preview-val, amikor lezárják a PR-t? Automatikusan meg kell semmisülnie. Ha ez nem történik meg, olyan környezetek fognak felhalmozódni, amelyekre már senki sem emlékszik.

Rontják a preview környezetek a SEO-t? Igen, ha indexelve lesznek — ilyenkor duplikált tartalom versenyez a production oldalaiddal. Állítsd be rajtuk a noindex értéket, ami azt is megakadályozza, hogy a crawlerek olyan forgalmat generáljanak, amelyért fizetned kell.