Päiväkirjan hakemistoDockup / kenttämuistio
Note / preview-environment-costs

Mitä preview-ympäristöt todella maksavat

Preview-ympäristöjen kustannukset kasvavat avoimien pull requestien, eivät tiimin koon, mukaan. Opi, mihin raha kuluu, mitä osia kannattaa jakaa ja miten previewt vanhennetaan, jotta viisi avointa PR:ää eivät tarkoita viittä stackia.

Preview-ympäristöt ovat yksi tehokkaimmista asioista, joita tiimi voi ottaa käyttöön. Reviewaaja napsauttaa linkkiä ja käyttää muutosta sen sijaan, että lukisi diffiä ja yrittäisi kuvitella lopputuloksen. Suunnitteluvirheet huomataan ennen mergeä. QA lakkaa olemasta erillinen vaihe.

Ne ovat myös kustannusrivi, joka todennäköisimmin kolminkertaistaa laskusi huomaamatta. Syynä on laskutoimitus, jota kukaan ei tee ominaisuutta käyttöön ottaessaan.

Laskutoimitus

Preview-ympäristön kustannukset kasvavat avoimien pull requestien määrän, eivät tiimin henkilömäärän tai mergejen määrän, mukaan.

Neljän hengen tiimillä, jossa review-kulttuuri toimii hyvin, voi olla millä tahansa hetkellä viidestä kahdeksaan avointa PR:ää. Jos jokainen niistä luo kokonaisen kopion stackistasi, ajat viidestä kahdeksaan tuotannon kopiota tuotannon rinnalla. Stack, jonka ajaminen maksaa 30 dollaria kuukaudessa, maksaa nyt 180–270 dollaria. Tätä ei näkynyt kenenkään arviossa, koska arvio koski yhtä ympäristöä.

Vielä pahempaa on se, että avoimia PR:iä kertyy juuri silloin, kun yllätyksiin on vähiten varaa: ennen julkaisua, refaktoroinnin aikana tai kun joku on lomalla ja hänen branchinsa jää avoimeksi kolmeksi viikoksi.

Mihin raha todella kuluu

Kaikki preview-ympäristön osat eivät maksa yhtä paljon. Kun tiedät, mikä osa maksaa mitäkin, kustannuksia on mahdollista hallita.

Sovelluskontit — kohtuullinen kustannus, ja sen arvoinen. Tämä on se osa, jonka todella haluat. Se myös skaalautuu alaspäin hyvin, koska preview ei tarvitse tuotannon muistimäärää.

Tietokannat — kallis osa. Erillinen tietokanta jokaista previewta varten on suurin yksittäinen kustannustekijä, ja yleensä vähiten tarpeellinen. Useimmat reviewt eivät tarvitse eristettyä tietokantaa, vaan jonkin tietokannan, jossa on uskottavaa dataa.

Build-minuutit — näkymättömiä ja kumuloituvia. Jokainen push avoimeen PR:ään käynnistää uuden buildin. Branch, johon tulee neljäkymmentä committia kahden viikon aikana, buildataan neljäkymmentä kertaa. Tämä on todellista kulutusta, joka ei näy käynnissä olevana resurssina, joten se jää kokonaan kustannusarvion ulkopuolelle.

Egress — pieni kustannus previewta kohden, suuri kokonaisuutena. Preview-URL:t löytyvät ja niitä crawlatään. Kahdeksan preview-ympäristön assetteja hakeva crawler tekee kahdeksankertaisen työn tuotantoon verrattuna, ja maksat kaikesta tästä.

Neljä keinoa leikata kustannuksia arvosta tinkimättä

Jaa tietokanta

Suurimmassa osassa muutoksia previewt voivat jakaa yhden tietokannan, joka on alustettu edustavalla datalla. Varaa eristetyt tietokannat vain PR:ille, jotka niitä todella tarvitsevat — migraatioille, skeemamuutoksille ja kaikelle tuhoavalle.

Käytännössä toimiva sääntö: eristetty tietokanta vain, kun PR koskettaa skeemaa. Kaikki muu jaetaan.

Pienennä previewta

Yhtä reviewaajaa palveleva preview ei tarvitse tuotannon resursseja. Puolikas muistimäärä ja murto-osa CPU:sta eivät yleensä näy reviewaajalle, mutta pienentävät kustannuksia olennaisesti.

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

Vanhennuta ne

Tämä on yksittäinen vaikutuksiltaan suurin muutos. Previewn ei pitäisi elää pull requestia pidempään.

Automaattinen teardown mergessä tai PR:n sulkeutuessa on perusvaatimus. Tiimit yllättää hylätty PR — branch, jonka joku avasi, siirtyi sitten muihin tehtäviin eikä koskaan sulkenut. Näitä ympäristöjä ajetaan kuukausia.

Enimmäisikään perustuva rajoitus kannattaa ottaa käyttöön: esimerkiksi kaikki yli neljätoista päivää vanhat previewt poistetaan PR:n tilasta riippumatta. Jos joku tarvitsee sen takaisin, se onnistuu yhdellä komennolla.

Pidä ne poissa hausta

Preview-URL:t päätyvät indeksoitaviksi. Se on huono asia kahdesta syystä: päällekkäinen sisältö kilpailee tuotantosivustosi kanssa, ja maksat crawler-liikenteestä ympäristöissä, joita kukaan ei käytä.

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

Dockupissa PR-previewt ovat palvelukohtaisia, ja ne voi ottaa käyttöön tai poistaa käytöstä eksplisiittisesti sen sijaan, että kyseessä olisi globaali asetus, jonka perit automaattisesti:

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

Listaus on se vaihe, jonka tiimit jättävät väliin ja jota ne myöhemmin katuvat. Ympäristöt, joita et pysty listaamaan, ovat ympäristöjä, joista maksat tietämättäsi.

Kerran kuussa tehtävä tarkistus

Kolme kysymystä, viisi minuuttia:

  1. Kuinka monta previewta on käynnissä? Vertaa määrää siihen, kuinka monta PR:ää on oikeasti avoinna.
  2. Kuinka vanha vanhin niistä on? Yli kaksi viikkoa vanha ympäristö on lähes varmasti hylätty.
  3. Millä niistä on oma tietokanta? Jos kyseessä ei ole skeemamuutos, omaa tietokantaa ei todennäköisesti tarvita.

Useimmat tiimit löytävät ainakin yhden ympäristön, joka liittyy kuukausia sitten mergeattuun PR:ään ja joka on edelleen käynnissä ja kerryttää laskua.

Hyödyt ilman yllätyksiä

Tämä ei ole argumentti preview-ympäristöjä vastaan. Se on argumentti sen puolesta, että niitä kohdellaan elinkaaren omaavana infrastruktuurina eikä yhtenä valintaruutuna.

Tämän oikein tekevät tiimit toimivat kolmella tavalla: previewt skaalataan pienemmiksi, previewt vanhennetaan ja ne osat jaetaan, jotka voidaan jakaa turvallisesti. Näin koko preview-jalanjälki pysyy yleensä yhden tuotantopalvelun kustannusten alapuolella — hinnalla, jolla niiden arvo on ilmeinen.

Yllättyvät tiimit ovat niitä, jotka ottivat ominaisuuden kerran käyttöön oikein eivätkä sen jälkeen enää tarkistaneet listaa.

Usein kysytyt kysymykset

Maksavatko preview-ympäristöt yhtä paljon kuin tuotanto? Ympäristöä kohden voivat maksaa, jos ne provisionoidaan täysin samalla tavalla. Pienemmäksi skaalattuna ja tietokannan jakavana preview maksaa yleensä vain murto-osan tuotannosta.

Pitäisikö jokaisella previewlla olla oma tietokanta? Vain silloin, kun muutos koskettaa skeemaa. Yksi alustettu jaettu tietokanta riittää useimpiin reviewihin ja poistaa suurimman kustannuserän.

Mitä previewlle tapahtuu, kun PR suljetaan? Sen pitäisi tuhoutua automaattisesti. Jos näin ei tapahdu, ympäristöjä kertyy PR:istä, joita kukaan ei enää muista.

Haittaavatko preview-ympäristöt SEO:a? Ne voivat haitata, jos ne indeksoidaan — päällekkäinen sisältö kilpailee tuotantosivujesi kanssa. Merkitse ne noindex-arvolla, mikä myös estää crawlereita tuottamasta liikennettä, josta maksat.