Hva preview-miljøer faktisk koster

Preview-miljøer er noe av det mest verdifulle et team kan ta i bruk. En reviewer klikker på en lenke og bruker endringen i stedet for å lese en diff og forestille seg hvordan den fungerer. Designfeil oppdages før merge. QA slutter å være en egen fase.

Samtidig er de kostnadsposten som lettest kan tredoble regningen uten at noen merker det, og årsaken er enkel aritmetikk som ingen regner på når funksjonen aktiveres.

Regnestykket

Kostnaden for preview-miljøer skalerer med antallet åpne pull requests, ikke med antallet personer på teamet eller antallet merges.

Et team på fire personer med en sunn review-kultur kan ha fem til åtte åpne PR-er til enhver tid. Hvis hver av dem provisionerer en full kopi av stacken, kjører du fem til åtte kopier av produksjon i tillegg til produksjon. En stack som koster 30 dollar i måneden å kjøre, koster nå 180–270 dollar, og ingenting av dette dukket opp i noen estimater, fordi estimatet gjaldt ett miljø.

Enda verre er det at åpne PR-er ofte sammenfaller med periodene hvor du har minst råd til overraskelser: før en release, under en refaktorering eller når noen har ferie og branchen deres blir stående åpen i tre uker.

Hvor pengene faktisk går

Ikke alle deler av en preview koster det samme, og det er nettopp kunnskapen om forskjellen som gjør kostnadene kontrollerbare.

Applikasjonscontainere — moderate kostnader, og verdt det. Dette er delen du faktisk ønsker deg. Den skalerer også godt ned, fordi en preview ikke trenger like mye minne som produksjon.

Databaser — den dyre delen. En dedikert database per preview er den største enkeltbidragsyteren, og som regel den minst nødvendige. De fleste reviews trenger ikke en isolert database; de trenger en database med plausible data.

Build-minutter — usynlige og kumulative. Hver push til en åpen PR starter en ny build. En branch med førti commits over to uker bygger førti ganger. Dette er reelle kostnader som aldri vises som en ressurs som kjører, og derfor ikke kommer med i den mentale kostnadskontrollen.

Egress — lite per preview, mye samlet. Preview-URL-er blir oppdaget og crawlet. En crawler som henter assets fra åtte preview-miljøer, gjør åtte ganger så mye arbeid som på produksjon, og du betaler for alt sammen.

Fire ting som kutter kostnadene uten å miste verdien

Del databasen

For de fleste endringer kan previews dele én database med representative testdata. Reserver isolerte databaser for PR-er som faktisk trenger dem — migreringer, schema-endringer og alt som er destruktivt.

Regelen som fungerer i praksis: isolert database bare når PR-en berører schemaet. Alt annet deles.

Skaler ned previewen

En preview som betjener én reviewer, trenger ikke produksjonens ressurser. Halvparten av minnet og en brøkdel av CPU-en er som regel usynlig for personen som reviewer, men gir en merkbar kostnadsreduksjon.

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

La dem utløpe

Dette er den enkeltendringen som har størst effekt. En preview bør ikke leve lenger enn pull requesten.

Automatisk nedrigging ved merge eller lukking er et minimumskrav. Det som ofte overrasker team, er den forlatte PR-en — branchen noen åpnet, sluttet å jobbe med og aldri lukket. Disse miljøene kan kjøre i månedsvis.

En maksimal levetid er en viktig sikkerhetsventil: Alle previews som er eldre enn for eksempel fjorten dager, fjernes uavhengig av PR-status. Hvis noen trenger miljøet tilbake, er det bare én kommando.

Hold dem ute av søk

Preview-URL-er blir indeksert. Det er problematisk av to grunner — duplikatinnhold som konkurrerer med produksjonssiden din, og crawler-trafikk du betaler for på miljøer ingen bruker.

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

I Dockup er PR-previews knyttet til den enkelte servicen og kan aktiveres eller deaktiveres eksplisitt, i stedet for å være en global innstilling du arver:

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

Det å liste dem opp er delen team hopper over, og senere angrer på. Miljøer du ikke kan telle opp, er miljøer du betaler for uten å vite det.

Revisjonen det er verdt å gjøre én gang i måneden

Tre spørsmål, fem minutter:

1. Hvor mange previews kjører? Sammenlign dette med hvor mange PR-er som faktisk er åpne.
2. Hvor gammel er den eldste? Alt som er eldre enn to uker, er nesten helt sikkert forlatt.
3. Hvilke har sin egen database? Alt som ikke er en schema-endring, trenger sannsynligvis ikke en egen database.

De fleste team finner minst ett miljø fra en PR som ble merget for flere måneder siden, men som fortsatt kjører og fortsatt faktureres.

Slik får du verdien uten overraskelsen

Dette er ikke et argument mot preview-miljøer. Det er et argument for å behandle dem som infrastruktur med en livssyklus, ikke som en avkrysningsboks.

Teamene som får dette til, gjør tre ting: De skalerer ned previews, lar previews utløpe og deler det som trygt kan deles. Da holder den samlede preview-infrastrukturen seg vanligvis under kostnaden for én enkelt produksjonsservice — en pris der det åpenbart er verdt det.

Teamene som blir overrasket, er de som aktiverte funksjonen én gang, gjorde alt riktig og aldri så på listen igjen.

Vanlige spørsmål

Koster preview-miljøer like mye som produksjon? Per miljø kan de gjøre det hvis de provisioneres identisk. Når de skaleres ned og deler en database, koster en preview vanligvis en brøkdel av produksjon.

Bør hver preview ha sin egen database? Bare når endringen berører schemaet. Én delt database med seedede data dekker de fleste reviews og fjerner den største kostnaden.

Hva skjer med en preview når PR-en lukkes? Den bør slettes automatisk. Hvis ikke vil du samle opp miljøer fra PR-er ingen husker.

Påvirker preview-miljøer SEO? Det kan de gjøre hvis de blir indeksert — duplikatinnhold som konkurrerer med produksjonssidene dine. Merk dem med noindex, noe som også hindrer crawlere i å generere trafikk du betaler for.