Un mediu de previzualizare are rost doar dacă spune adevărul. Dacă staging-ul rulează pe alt server, cu altă versiune de PHP sau cu altă configurație de cache decât producția, atunci fiecare aprobare dată pe el poartă un asterisc invizibil: aici a mers, sperăm că și pe live e la fel. Cele mai multe surprize de pe staging vin din asteriscul acela, nu din neglijența cuiva.
Ne-am construit platforma tocmai ca să scăpăm de asteriscul ăsta. Fiecare proiect pe care îl găzduim poate primi medii de branch care rulează exact aceeași platformă ca producția: aceleași containere securizate, aceeași configurație de server web, același TLS, provizionate separat pentru fiecare branch. Cum se comportă o modificare pe staging, așa se comportă și pe live, pentru că dedesubt e același software, cu aceeași configurație.
Iată cum funcționează asta în practică și de ce tratăm paritatea mediilor drept esența ofertei, nu un bonus.
Paritatea începe pe calculatorul dezvoltatorului
Regula platformei identice nu pornește de la staging, ci mai devreme. În timpul dezvoltării rulăm local exact platforma de producție, inclusiv TLS. Containerele cu care lucrează un dezvoltator pe propriul calculator sunt aceleași imagini securizate care vor servi site-ul în producție. Nu există nicio etapă de adaptare între "merge în dezvoltare" și "merge în producție", pentru că dezvoltarea rulează pe platforma producției, doar că pe date de dezvoltare.
Asta elimină pe tăcute o întreagă categorie de erori. Diferențe la extensiile PHP, la regulile de rescriere ale serverului web, la felul în care sunt configurate încărcările de fișiere, cron-ul sau cache-ul: astea sunt sursele clasice ale lui "la mine merge", și nu au cum să apară când există o singură definiție de mașină de la bun început. Un dezvoltator care vede că o funcționalitate merge local a văzut-o deja mergând pe platforma de producție, doar că ceva mai devreme.
Fiecare branch poate avea propriul mediu
Când o modificare e gata de arătat, nu o urcăm pe un server de staging comun, unde ar sta la coadă după alte modificări fără legătură cu ea. Un branch primește propriul mediu: propriul URL, propria bază de date, propriile containere, care rulează branch-ul respectiv și nimic altceva. Vezi funcționalitatea reală la o adresă reală, pe dispozitivele tale, în ritmul tău, iar mediul dispare după ce modificarea e integrată.
Pentru că fiecare branch are mediul lui, mai multe lucrări pot fi evaluate în paralel fără să se încurce una pe alta. O schimbare în modelul de conținut, o revizuire de design și o actualizare de modul stau fiecare în mediul ei, fiecare se comportă exact ca pe live și niciuna nu le afectează pe celelalte. Feedback-ul rămâne legat de modificarea la care se referă.
Asta lărgește și cercul celor care pot participa la evaluare. Un mediu de branch are un URL normal, așa că îl poți trimite unui coleg din alt departament, îl poți deschide în ședința în care se ia decizia sau îl poți verifica de pe același telefon pe care îl vor folosi vizitatorii tăi. Nimeni nu are nevoie de un dezvoltator lângă el ca să vadă rezultatul.
Aceleași containere, același model de configurație
Paritatea nu ține doar de mașini. Un site Drupal își ține o mare parte din comportament în configurație: tipuri de conținut, câmpuri, permisiuni, moduri de afișare, setări de cache. La proiectele noastre configurația asta stă în cod și merge împreună cu branch-ul, lansată peste tot prin același proces. Un mediu de staging nu rulează deci doar aceleași containere ca live-ul, ci și exact configurația pe care lansarea o va pune pe live.
Asta dă greutate aprobării. Ce aprobi pe staging nu e o imitație, e chiar modificarea: același cod, aceeași configurație, aceeași platformă. Lansarea pe live devine o repetare a ceva ce s-a întâmplat deja o dată, nu o primă încercare făcută în fața publicului. Iar când o evaluare chiar scoate la iveală o problemă, înseamnă că sistemul și-a făcut treaba: surpriza a apărut în singurul loc unde nu costă nimic, iar corectura intră în același branch, care trece din nou prin aprobare.
Și lansarea în sine e repetată dinainte
Pe platforma noastră o lansare e o acțiune explicită, consemnată, și e același mecanism pe fiecare mediu. Până să ajungă o modificare pe live, lansarea ei a rulat deja cel puțin o dată pe un mediu care se comportă ca live-ul, deci procedura de lansare e testată odată cu funcționalitatea. Fiecare versiune e consemnată, iar la o versiune anterioară revii printr-o singură acțiune. Dacă două lansări pornesc vreodată spre același mediu în același timp, așteaptă una după alta în loc să se ciocnească, așa că istoricul versiunilor rămâne liniar și de încredere.
Pentru clienți, efectul vizibil e că ieșirea pe live nu mai e un moment de tensiune trecut în calendar. Nu există o fereastră lungă de mentenanță și nici o ședință cu toată lumea la telefon, pentru că nimic din lansare nu se întâmplă pentru prima oară.
Baza de staging e curățată de datele personale
Testarea realistă are nevoie de date realiste: volume reale de conținut, structuri reale, cazuri-limită reale. De oameni reali, în schimb, nu are nevoie. Ori de câte ori o copie a bazei de date ajunge într-un mediu care nu e de producție, e curățată de date personale pe drum. Numele, adresele de e-mail și celelalte câmpuri personale sunt anonimizate înainte ca copia să ajungă la destinație, așa că un mediu de staging îți oferă date care arată ca cele din producție, fără să țină date personale acolo unde nu le e locul.
Nimeni nu trebuie să țină minte să facă asta, și tocmai asta contează. Curățarea face parte din operațiunea de copiere, așa că nicio vineri după-amiază grăbită nu poate produce o bază de staging necurățată. Protecția datelor care depinde de cineva care ține minte un pas nu e protecție, e noroc.
Staging-ul nu poate trimite e-mailuri reale
Celălalt accident clasic de staging e e-mail-ul: o comandă de test, o notificare de probă, un cron la care nu s-a gândit nimeni, care ajung dintr-odată în căsuțe de e-mail reale. Pe platforma noastră, mediile care nu sunt de producție pur și simplu nu pot trimite e-mailuri reale. Mesajele care pleacă sunt prinse într-un colector de e-mailuri, unde și noi, și tu le putem deschide, le putem verifica conținutul și formatarea și putem urmări întregul flux de la un capăt la altul.
Garanția asta schimbă cât de temeinic poți testa. Resetările de parolă, confirmările de comandă și lanțurile de notificări în mai mulți pași pot fi rulate de câte ori e nevoie până ies bine, cu certitudinea că niciun destinatar real nu va vedea vreodată o probă. Siguranța o garantează mediul, nu un punct de pe o listă de verificare.
Ce îți aduce paritatea
Câștigul practic e că aprobarea devine o decizie, nu o ghicitoare. Când te uiți la un mediu de branch și spui "dă-i drumul", ai văzut varianta adevărată: comportamentul real, configurația reală, pe platforma reală. Emoțiile dinaintea lansării vin în mare parte din diferențele necunoscute dintre locul unde a fost testată o modificare și locul unde va rula. Elimină diferențele și emoțiile nu mai au de unde să vină. Pentru asta există un mediu de staging, și de asta ne investim efortul în previzualizări care spun adevărul, nu în previzualizări care doar există.