Vad preview environments faktiskt kostar

Preview environments är en av de mest värdefulla funktionerna ett team kan aktivera. En reviewer klickar på en länk och använder ändringen i stället för att läsa en diff och föreställa sig resultatet. Designproblem upptäcks före merge. QA slutar vara en separat fas.

De är också den kostnadspost som mest sannolikt tyst tredubblar din faktura, och orsaken är enkel matematik som ingen räknar på när funktionen aktiveras.

Matematiken

Kostnaden för preview environments skalar med antalet öppna pull requests, inte med antalet personer i teamet eller antalet merges.

Ett fyrmannateam med en sund reviewkultur kan ha fem till åtta öppna PR:er när som helst. Om varje PR provisionerar en komplett kopia av stacken kör du fem till åtta kopior av produktion parallellt med produktion. En stack som kostar 30 dollar i månaden kostar nu 180–270 dollar, och inget av det fanns med i någons uppskattning, eftersom uppskattningen gällde en miljö.

Ännu värre är att öppna PR:er ofta sammanfaller med de perioder då du har minst råd med överraskningar: inför en release, under en refaktorering, eller när någon är på semester och deras branch förblir öppen i tre veckor.

Vart pengarna faktiskt går

Alla delar av en preview kostar inte lika mycket, och det är kunskapen om skillnaden som gör kostnaden kontrollerbar.

Application containers — måttlig kostnad och väl värda den. Det här är den del du faktiskt vill ha. Den skalar dessutom ned bra, eftersom en preview inte behöver lika mycket minne som produktion.

Databaser — den dyra delen. En separat databas per preview är den största enskilda kostnadsposten, och oftast den minst nödvändiga. De flesta reviews behöver inte en isolerad databas; de behöver en databas med realistiska data.

Build minutes — osynliga och kumulativa. Varje push till en öppen PR bygger om. En branch med fyrtio commits under två veckor bygger fyrtio gånger. Det här är en verklig kostnad som aldrig visas som en körande resurs, och därför helt undgår den mentala granskningen.

Egress — liten per preview, stor totalt. Preview-URL:er upptäcks och crawlas. En crawler som hämtar dina assets från åtta preview environments gör åtta gånger så mycket arbete som på produktion, och du betalar för alltihop.

Fyra saker som minskar kostnaden utan att värdet försvinner

Dela databasen

För de flesta ändringar kan previews dela en databas som är seedad med representativa data. Spara isolerade databaser till de PR:er som faktiskt behöver dem — migrations, schemaändringar och allt destruktivt.

Regeln som fungerar i praktiken: isolerad databas endast när PR:en ändrar schemat. Allt annat delas.

Skala ned previewn

En preview som används av en enda reviewer behöver inte produktionsmiljöns resurser. Hälften så mycket minne och en bråkdel av CPU:n är vanligtvis osynligt för personen som gör review och betydligt billigare.

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

Låt dem löpa ut

Den förändring som ger störst effekt. En preview ska inte leva längre än sin pull request.

Automatisk teardown vid merge eller stängning är en självklar grundfunktion. Det som överraskar team är den övergivna PR:en — branchen som någon öppnade, sedan slutade arbeta med och aldrig stängde. De miljöerna körs i månader.

En maximal livslängd är den backstop som är värd att ha: alla previews som är äldre än, säg, fjorton dagar tas bort oavsett PR:ens status. Om någon behöver den igen kan den återskapas med ett kommando.

Håll dem borta från sökningar

Preview-URL:er indexeras. Det är dåligt av två skäl — duplicerat innehåll som konkurrerar med produktionswebbplatsen och crawlertrafik som du betalar för på miljöer som ingen använder.

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

I Dockup är PR-previews separata per service och kan aktiveras eller inaktiveras uttryckligen, i stället för att vara en global inställning som du ärver:

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

Att lista dem är det team brukar hoppa över och sedan ångra. Miljöer som du inte kan lista är miljöer du betalar för utan att veta om det.

Granskningen som är värd att göra en gång i månaden

Tre frågor, fem minuter:

1. Hur många previews körs? Jämför det med hur många PR:er som faktiskt är öppna.
2. Hur gammal är den äldsta? Allt som är äldre än två veckor är nästan säkert övergivet.
3. Vilka har en egen databas? Allt som inte är en schemaändring behöver förmodligen ingen egen databas.

De flesta team hittar minst en miljö från en PR som mergades för flera månader sedan, men som fortfarande körs och fortfarande kostar pengar.

Få värdet utan överraskningen

Inget av det här är ett argument mot preview environments. Det är ett argument för att behandla dem som infrastruktur med en livscykel, inte som en kryssruta.

Team som gör det här rätt gör tre saker: previews skalas ned, previews löper ut och previews delar det som säkert kan delas. Då hålls vanligtvis hela preview-footprinten under kostnaden för en enda produktionstjänst — vilket är en prisnivå där värdet uppenbart överväger kostnaden.

Team som blir överraskade är de som aktiverade funktionen en gång, gjorde det korrekt och sedan aldrig tittade på listan igen.

Vanliga frågor

Kostar preview environments lika mycket som produktion? Per miljö kan de göra det, om de provisioneras identiskt. När en preview skalas ned och delar databas kostar den vanligtvis en bråkdel av produktion.

Bör varje preview ha en egen databas? Endast när ändringen påverkar schemat. En delad, seedad databas täcker de flesta reviews och tar bort den största kostnaden.

Vad händer med en preview när PR:en stängs? Den bör förstöras automatiskt. Om den inte gör det samlar du på dig miljöer från PR:er som ingen längre minns.

Skadar preview environments SEO? Det kan de göra om de indexeras — duplicerat innehåll som konkurrerar med dina produktionssidor. Märk dem med noindex, vilket också hindrar crawlers från att generera trafik som du betalar för.