Quanto costano davvero gli ambienti di preview
Il costo degli ambienti di preview cresce con le pull request aperte, non con le dimensioni del team. Scopri dove si nasconde la spesa, quali componenti condividere e come far scadere le preview, così cinque PR aperte non si trasformano in cinque stack.
Gli ambienti di preview sono una delle funzionalità con il maggior impatto che un team possa attivare. Un reviewer fa clic su un link e prova la modifica invece di leggere un diff e immaginarne il risultato. Il design individua i problemi prima del merge. La QA smette di essere una fase separata.
Sono anche la voce di costo più propensa a far triplicare silenziosamente la bolletta, per un motivo basato su un calcolo aritmetico che nessuno fa nel momento in cui attiva la funzionalità.
Il calcolo
Il costo degli ambienti di preview cresce in base al numero di pull request aperte, non al numero di persone nel team o al numero di merge.
Un team di quattro persone con una sana cultura della code review può avere da cinque a otto PR aperte in qualsiasi momento. Se ognuna effettua il provisioning di una copia completa dello stack, significa eseguire da cinque a otto copie della produzione oltre alla produzione stessa. Uno stack che costa 30 $ al mese arriva a costare 180–270 $, e questa spesa non compare in nessuna stima, perché la stima riguardava un solo ambiente.
Peggio ancora, il numero di PR aperte tende a crescere proprio nei momenti in cui puoi permetterti meno sorprese: prima di una release, durante un refactor, quando qualcuno è in vacanza e il suo branch resta aperto per tre settimane.
Dove finiscono davvero i soldi
Non tutte le componenti di una preview hanno lo stesso costo. Capire quali incidono di più è ciò che permette di tenere la spesa sotto controllo.
Application container — costo moderato, e ne vale la pena. È la componente che vuoi davvero avere. È anche quella che si ridimensiona meglio, perché una preview non ha bisogno della memoria della produzione.
Database — la componente più costosa. Un database dedicato per ogni preview è il principale fattore di costo, e di solito è quello meno necessario. La maggior parte delle review non ha bisogno di un database isolato: ha bisogno di un database con dati plausibili.
Minuti di build — invisibili e cumulativi. Ogni push su una PR aperta avvia una nuova build. Un branch con quaranta commit in due settimane viene compilato quaranta volte. È una spesa reale che non compare mai come risorsa in esecuzione, quindi sfugge completamente a una verifica mentale.
Egress — ridotto per ogni preview, elevato nel complesso. Gli URL delle preview vengono scoperti e sottoposti a crawling. Un crawler che scarica i tuoi asset da otto ambienti di preview sta svolgendo un lavoro otto volte maggiore rispetto a quello su produzione, e paghi ogni singola richiesta.
Quattro interventi per ridurre i costi senza perdere il valore
Condividi il database
Per la maggior parte delle modifiche, le preview possono condividere un unico database inizializzato con dati rappresentativi. Riserva i database isolati alle PR che ne hanno davvero bisogno: migration, modifiche allo schema e qualsiasi operazione distruttiva.
La regola che funziona nella pratica è questa: database isolato solo quando la PR modifica lo schema. Per tutto il resto, si condivide.
Ridimensiona la preview
Una preview utilizzata da un solo reviewer non ha bisogno delle risorse della produzione. Dimezzare la memoria e ridurre a una frazione la CPU di solito è impercettibile per chi esegue la review, ma consente di risparmiare in modo significativo.
dockup resources my-project/my-api --memory 512 --cpu 0.5
Imposta una scadenza
È la modifica con il maggiore impatto. Una preview non dovrebbe sopravvivere alla propria pull request.
Il teardown automatico al merge o alla chiusura è il minimo indispensabile. A cogliere impreparati i team è la PR abbandonata: il branch che qualcuno ha aperto, dal quale è stato spostato e che non ha mai chiuso. Questi ambienti restano in esecuzione per mesi.
Vale la pena impostare un'età massima come misura di sicurezza: qualsiasi preview più vecchia, per esempio, di quattordici giorni viene rimossa indipendentemente dallo stato della PR. Se serve di nuovo, basta un comando per ricrearla.
Escludile dalla ricerca
Gli URL delle preview vengono indicizzati. È un problema per due motivi: contenuti duplicati in competizione con il tuo sito di produzione e traffico dei crawler che paghi su ambienti che nessuno sta utilizzando.
dockup noindex my-project/my-api --on
Su Dockup, le preview delle PR sono configurabili per singolo servizio e possono essere abilitate o disabilitate esplicitamente, invece di essere un'impostazione globale ereditata:
dockup pr-preview my-project/my-api --on
dockup preview list my-project/my-api --json
dockup preview delete 128 my-project/my-api
Elencarle è il passaggio che i team saltano e poi rimpiangono. Gli ambienti che non puoi enumerare sono ambienti per i quali stai pagando senza saperlo.
L'audit da fare una volta al mese
Tre domande, cinque minuti:
- Quante preview sono in esecuzione? Confronta il numero con quello delle PR effettivamente aperte.
- Quanto è vecchia la più datata? Qualsiasi ambiente che supera le due settimane è quasi certamente abbandonato.
- Quali hanno un database dedicato? Tutto ciò che non modifica lo schema probabilmente non ne ha bisogno.
La maggior parte dei team trova almeno un ambiente appartenente a una PR sottoposta a merge mesi prima, ancora in esecuzione e ancora fatturato.
Ottenere il valore senza sorprese
Niente di tutto questo è un argomento contro gli ambienti di preview. È un invito a considerarli come infrastruttura con un proprio ciclo di vita, non come una semplice casella da spuntare.
I team che gestiscono bene questo aspetto fanno tre cose: ridimensionano le preview, le fanno scadere e condividono in sicurezza ciò che può essere condiviso. In questo modo, l'intera infrastruttura delle preview resta di solito al di sotto del costo di un singolo servizio di produzione: un prezzo al quale il loro valore è evidente.
I team che si ritrovano con una sorpresa sono quelli che hanno attivato la funzionalità una volta, correttamente, e poi non hanno più controllato l'elenco.
Domande frequenti
Gli ambienti di preview costano quanto la produzione? Per singolo ambiente possono costare altrettanto, se vengono sottoposti a provisioning in modo identico. Ridimensionando le risorse e condividendo il database, una preview costa in genere una frazione della produzione.
Ogni preview dovrebbe avere un database dedicato? Solo quando la modifica riguarda lo schema. La condivisione di un unico database inizializzato con dati rappresentativi copre la maggior parte delle review ed elimina il principale fattore di costo.
Cosa succede a una preview quando la PR viene chiusa? Dovrebbe essere eliminata automaticamente. In caso contrario, accumulerai ambienti appartenenti a PR che nessuno ricorda più.
Gli ambienti di preview danneggiano la SEO?
Possono farlo se vengono indicizzati: contenuti duplicati in competizione con le pagine di produzione. Imposta noindex, così impedirai anche ai crawler di generare traffico che paghi.