Orice dezvoltator știe replica "la mine merge". De obicei vine cu o ridicare din umeri, imediat după ce ceva care mergea perfect în dezvoltare a făcut ceva ciudat pe serverul live. Undeva între cele două medii, o diferență de versiune, de setare sau de infrastructură a făcut ca același cod să se poarte altfel.
Acum câțiva ani am decis că nu vrem ca decalajul ăsta să existe deloc. Astăzi, când cineva din echipa noastră lucrează la site-ul unui client, calculatorul lui rulează exact platforma de producție: aceleași containere securizate pe care le rulăm pe serverele live, aceeași configurație de server web, același TLS, aceeași legătură între toate piesele. Nu o imitație ușoară a producției. Producția însăși, pornită local.
Articolul ăsta explică de ce ne-am construit platforma așa, ce elimină din ziua lansării și cât de liniștit pleacă munca spre live datorită ei.
De unde vine decalajul
Decalajul dintre dezvoltare și producție nu apare pentru că cineva e neglijent. Apare pentru că cele două medii au roluri diferite. Un mediu de dezvoltare e optimizat pentru comoditate: rapid de instalat, ușor de resetat, tolerant cu greșelile. Un server de producție e optimizat pentru securitate și stabilitate: închis, întărit, strict cu permisiunile. Lăsate să evolueze separat, cele două se îndepărtează într-o sută de detalii mărunte. O versiune de PHP aici, o directivă de server web dincolo, un strat de cache care există într-un loc și lipsește în celălalt.
Luată separat, fiecare diferență e inofensivă. Problema e că, în realitate, codul și configurația se influențează reciproc, iar fiecare diferență e un loc în care comportamentul poate devia. Când testezi pe o configurare care doar seamănă cu producția, fiecare lansare cară după ea un rest de presupuneri neverificate. În cele mai multe zile, restul ăsta nu se vede. În ziua nepotrivită, îți mănâncă toată după-amiaza.
Ce înseamnă "identic" în practică
Platforma noastră de găzduire rulează site-urile în containere securizate pe care le construim și le întreținem noi. Când un dezvoltator pornește un proiect local, platforma pornește aceleași containere pe calculatorul lui: același runtime PHP cu aceleași extensii și aceleași limite, același server web cu aceleași fișiere de configurare, același motor de bază de date, același cache, aceeași structură de directoare și același model de permisiuni. Site-ul răspunde pe un domeniu local, prin TLS, cu certificate pe care browserul le acceptă, pentru că producția rulează pe TLS, și la fel trebuie să ruleze orice pretinde că o reproduce.
Consecința e simplă: dacă merge local, merge și live, pentru că local și live sunt aceeași platformă. Nu există niciun pas de adaptare de la mediul de dezvoltare la server. Mediul călătorește odată cu site-ul.
Scurtează și acomodarea celor noi. Un dezvoltator care intră într-un proiect rulează o singură comandă și are producția în față, cu TLS cu tot, în loc să își piardă primele zile asamblând de mână o aproximare a ei și să îi descopere lipsurile luni întregi după aceea.
Surprizele care dispar cu totul
O întreagă categorie de probleme din ziua lansării pur și simplu nu mai are unde să apară. O regulă de rescriere care se poartă altfel de la un server web la altul nu te mai poate lovi când există o singură configurație de server web. O limită de încărcare sau un plafon de memorie diferit între medii nu mai poate produce o eroare care apare doar pe live. Avertismentele de conținut mixt, care ies de obicei la iveală prima dată când un site ajunge în spatele TLS, nu mai pot apărea târziu, pentru că site-ul a stat în spatele TLS de la prima pagină încărcată local.
Ce mai poate merge prost sunt codul și conținutul în sine, exact acolo unde trebuie să fie atenția. Când ceva pică în dezvoltare, știm că ar fi picat și pe live, așa că se repară pe loc. Când ceva trece, înseamnă că trece cu adevărat. Testarea nu mai e o repetiție în alt teatru, ci spectacolul propriu-zis, doar mai devreme.
Lansările devin plictisitoare, în sensul bun
Aceeași filozofie se vede și în felul în care pleacă schimbările spre live. O lansare pe platforma noastră e o versiune explicită, cu istoric: pleacă o stare concretă, cunoscută a codului, versiunea rămâne înregistrată, iar dacă ceva pare în neregulă, revii la versiunea anterioară cu o singură acțiune. Două lansări spre același mediu se așază la coadă și rulează pe rând, în loc să se ciocnească. Nimic din toate astea nu e eroic. E banal cu bună știință.
Pune asta lângă un mediu de dezvoltare care spune adevărul și lansările își schimbă firea. Nu mai sunt evenimente care cer o vineri liniștită și toată echipa cu sufletul la gură. Schimbările mici pleacă în versiuni mici, des, pentru că fiecare a rulat deja pe platforma de producție înainte să iasă de pe calculatorul de dezvoltare.
Aceeași regulă pentru fiecare mediu
Paritatea asta nu se oprește la calculatorul local. Când un proiect are nevoie de un mediu de staging sau de un mediu temporar în care să previzualizeze o anumită lucrare, platforma noastră îl creează după aceeași rețetă: aceleași containere, aceeași configurație, același TLS. Un client care se uită la o schimbare pe un link de previzualizare vede exact cum se va comporta ea în producție, nu o aproximare.
Copiile bazei de date aduse în mediile astea sunt curățate de date personale pe drum, așa că realismul nu se plătește cu confidențialitatea. Rezultatul e un lanț de medii, de la laptopul de dezvoltare la previzualizare și până la producție, care diferă prin date și prin public, dar niciodată prin comportament.
De ce am construit platforma noi, în loc să o asamblăm din bucăți
Avem propria platformă de găzduire administrată, și asta face totul posibil. Pentru că noi controlăm cum e alcătuită producția, putem face aceeași compoziție să ruleze oriunde și le putem ține pe cele două sincronizate: când platforma de producție se actualizează, platforma de dezvoltare se actualizează odată cu ea, pentru că sunt construite din aceleași piese. Paritatea nu e o regulă pe care o impunem cu disciplină. E o proprietate a sistemului, și doar așa rezistă paritatea și în săptămânile aglomerate.
Drupal merită, de altfel, o asemenea fundație. Framework-ul în sine e disciplinat cu configurația și cu lansările, cu un model clar de mutat schimbările între medii. Pe o infrastructură care se comportă identic peste tot, disciplina asta dă roade pe deplin.
Ce înseamnă asta dacă îți construim sau îți găzduim site-ul
O vei simți mai ales ca pe o absență. Lansări care trec în liniște. Schimbări care vin când au fost promise și se poartă la fel ca în demonstrație. Niciun "în staging mergea" care să se strecoare în proiectul tău. Iar sub calmul ăsta stă un câștig practic: pentru că lansarea are risc mic, îmbunătățirile pleacă în pași mici în loc să se strângă în versiuni mari și tensionate. Un site care primește multe schimbări mici și sigure rămâne modern; unul care așteaptă următoarea actualizare mare, pregătită cu grijă, nu.
Obiectivul a fost ca "la mine merge" și "merge live" să devină aceeași propoziție. Tot restul, lansările mai calme, iterația mai rapidă, drumul mai scurt de la idee la producție, decurge din decizia asta.