Cât costă de fapt mediile de preview

Mediile de preview sunt printre cele mai eficiente lucruri pe care le poate activa o echipă. Un reviewer accesează un link și folosește schimbarea, în loc să citească un diff și să încerce să și-o imagineze. Problemele de design sunt descoperite înainte de merge. QA nu mai este o etapă separată.

În același timp, ele sunt linia de cost cu cele mai mari șanse să îți tripleze discret factura, iar motivul este un calcul pe care nimeni nu îl face în momentul în care activează această funcționalitate.

Calculul

Costul unei medii de preview crește odată cu numărul de pull request-uri deschise, nu cu numărul de persoane din echipă sau cu numărul de merge-uri.

O echipă de patru persoane, cu o cultură sănătoasă a code review-ului, poate avea între cinci și opt PR-uri deschise în orice moment. Dacă fiecare creează o copie completă a stack-ului, rulezi între cinci și opt copii ale producției, pe lângă producție. Un stack care costă 30 de dolari pe lună ajunge acum să coste între 180 și 270 de dolari, iar această sumă nu a apărut în estimarea nimănui, deoarece estimarea viza o singură mediu.

Mai rău, PR-urile deschise se înmulțesc exact în perioadele în care îți permiți cel mai puțin surprize: înainte de un release, în timpul unui refactor sau când cineva este în concediu și branch-ul său rămâne deschis trei săptămâni.

Unde se duc de fapt banii

Nu toate componentele unui preview costă la fel, iar faptul că știi care sunt diferențele îți permite să controlezi costurile.

Containerele aplicației — cost moderat și merită. Aceasta este componenta de care ai nevoie cu adevărat. Este și componenta care poate fi redusă cel mai ușor, deoarece un preview nu are nevoie de memoria producției.

Bazele de date — componenta costisitoare. O bază de date dedicată pentru fiecare preview este cel mai mare contributor la cost și, de obicei, cea mai puțin necesară. Majoritatea review-urilor nu au nevoie de o bază de date izolată; au nevoie de o bază de date cu date plauzibile.

Minutele de build — invizibile și cumulative. Fiecare push către un PR deschis declanșează un nou build. Un branch cu patruzeci de commit-uri de-a lungul a două săptămâni este construit de patruzeci de ori. Este un cost real care nu apare niciodată ca resursă care rulează, așa că scapă complet auditului mental.

Egress — mic pentru fiecare preview, mare cumulat. URL-urile de preview sunt descoperite și crawl-uite. Un crawler care îți descarcă asset-urile din opt medii de preview face de opt ori mai multă muncă decât pe producție, iar tu plătești pentru toată această activitate.

Patru lucruri care reduc costurile fără să elimine avantajele

Partajează baza de date

Pentru majoritatea schimbărilor, preview-urile pot folosi în comun o bază de date populată cu date reprezentative. Păstrează bazele de date izolate pentru PR-urile care chiar au nevoie de ele — migrări, modificări de schemă sau orice schimbare distructivă.

Regula care funcționează în practică: bază de date izolată doar atunci când PR-ul modifică schema. Toate celelalte folosesc baza comună.

Redu dimensiunea preview-ului

Un preview folosit de un singur reviewer nu are nevoie de resursele producției. Jumătate din memorie și o fracțiune din CPU sunt, de obicei, imperceptibile pentru persoana care face review-ul, dar reduc semnificativ costurile.

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

Configurează expirarea

Aceasta este schimbarea cu cel mai mare impact. Un preview nu ar trebui să supraviețuiască pull request-ului său.

Ștergerea automată la merge sau la închiderea PR-ului este minimul necesar. Ceea ce le creează probleme echipelor este PR-ul abandonat — branch-ul pe care cineva l-a deschis, apoi a fost mutat pe altă activitate și nu l-a mai închis. Aceste medii rulează luni întregi.

Merită să ai și o vârstă maximă: orice preview mai vechi de, să spunem, paisprezece zile este eliminat indiferent de starea PR-ului. Dacă cineva are din nou nevoie de el, îl poate recrea printr-o singură comandă.

Exclude-le din căutare

URL-urile de preview sunt indexate. Acest lucru este problematic din două motive — conținut duplicat care concurează cu site-ul tău de producție și trafic de crawler pentru care plătești, pe medii pe care nu le folosește nimeni.

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

În Dockup, preview-urile pentru PR-uri sunt configurate per serviciu și pot fi activate sau dezactivate explicit, în loc să fie o setare globală moștenită:

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

Listarea lor este partea pe care echipele o sar și pe care ajung să o regrete. Mediile pe care nu le poți enumera sunt medii pentru care plătești fără să știi.

Auditul pe care merită să îl faci o dată pe lună

Trei întrebări, cinci minute:

1. Câte preview-uri rulează? Compară acest număr cu numărul de PR-uri care sunt efectiv deschise.
2. Cât de vechi este cel mai vechi? Orice mediu mai vechi de două săptămâni este aproape sigur abandonat.
3. Care dintre ele au propria bază de date? Orice schimbare care nu vizează schema probabil nu are nevoie de una.

Majoritatea echipelor găsesc cel puțin un mediu provenit dintr-un PR care a fost făcut merge cu luni în urmă, dar care încă rulează și continuă să genereze costuri.

Cum obții avantajele fără surprize

Nimic din toate acestea nu este un argument împotriva mediilor de preview. Este un argument pentru tratarea lor ca infrastructură cu un ciclu de viață, nu ca o simplă bifă.

Echipele care gestionează corect acest aspect fac trei lucruri: reduc dimensiunea preview-urilor, le configurează expirarea și partajează în siguranță ceea ce poate fi partajat. De obicei, astfel, întregul set de medii de preview rămâne sub costul unui singur serviciu de producție — un preț la care merită în mod evident.

Echipele care sunt luate prin surprindere sunt cele care au activat funcționalitatea o singură dată, au configurat-o corect și apoi nu au mai verificat niciodată lista.

Întrebări frecvente

Costă mediile de preview la fel de mult ca producția? Pe mediu, pot costa la fel, dacă sunt create identic. Dacă sunt dimensionate mai redus și folosesc o bază de date comună, un preview costă de obicei o fracțiune din costul producției.

Ar trebui ca fiecare preview să aibă propria bază de date? Doar atunci când schimbarea modifică schema. O bază de date comună, populată cu date inițiale, este suficientă pentru majoritatea review-urilor și elimină cea mai mare componentă de cost.

Ce se întâmplă cu un preview atunci când PR-ul este închis? Ar trebui să fie șters automat. Dacă nu se întâmplă acest lucru, vei acumula medii provenite din PR-uri de care nu își mai amintește nimeni.

Afectează mediile de preview SEO-ul? Pot să îl afecteze dacă sunt indexate — conținut duplicat care concurează cu paginile de producție. Marchează-le cu noindex, ceea ce împiedică și crawler-ele să genereze trafic pentru care plătești.