În ziua unei lansări, noi urmărim un anumit fel de liniște. Munca e gata, versiunea nouă intră live și nu se mai întâmplă nimic. Fără agitație, fără respirație ținută, fără mesajul care roagă pe toată lumea să stea pe lângă tastatură în ora următoare. Când o lansare e cu adevărat plictisitoare, înseamnă că fiecare întrebare interesantă a primit răspuns înainte de lansare, nu în timpul ei.
Liniștea asta nu e noroc. E construită, la fel cum construiești orice altceva pe care vrei să te bazezi ani de zile. Cu timpul, ne-am așezat procesul de lansare în jurul unei singure idei: o lansare trebuie să fie un eveniment explicit, înregistrat și reversibil, iar tot ce ține de ea trebuie decis înainte ca cineva să apese pe ceva.
Articolul ăsta e despre cum arată asta în practică și de ce credem că lansările fără surprize sunt unul dintre cele mai valoroase lucruri pe care un client nu apucă niciodată să le observe.
O lansare e o decizie, nu un efect secundar
Pe platforma noastră de găzduire, trimiterea codului în repository nu lansează nimic. Separarea e intenționată. Codul ajunge în repository ori de câte ori o bucată de lucru e gata să fie văzută și verificată de ceilalți. Lansarea e o acțiune separată, explicită, făcută de o persoană care a decis că exact această versiune trebuie să intre live acum.
Distincția pare măruntă, dar schimbă totul. Când lansarea e un efect secundar al dezvoltării de zi cu zi, site-ul live se schimbă ori de câte ori se nimerește ca cineva să termine ceva, și nimeni nu poate spune cu certitudine ce a intrat live și când. Când lansarea e o decizie, site-ul live se schimbă după un calendar ales de cineva, cu un set cunoscut de modificări atașat. O întrebare de genul "ce s-a schimbat marți" are un răspuns exact, în loc să se transforme în săpături arheologice.
Se schimbă și atmosfera din dezvoltare. Munca în curs poate fi trimisă, discutată și îmbunătățită fără teama că o idee pe jumătate terminată se strecoară spre producție. Repository-ul e locul unde munca se coace. Lansarea e momentul în care pleacă în lume. Ținute separat, cele două momente scapă amândouă de presiune.
Fiecare lansare lasă o urmă
Fiecare lansare e înregistrată ca o versiune: ce a intrat live, când, în ce mediu și cum a decurs. Istoricul ăsta stă în portalul de client, lângă tichete, facturi și starea proiectului, așa că istoricul lansărilor unui site nu mai stă în capul celui care s-a nimerit să facă treaba. E o listă pe care o poate citi oricine e implicat în proiect.
Registrul își face treaba în momentele calme la fel ca în cele urgente. Când site-ul începe să se comporte altfel, prima întrebare utilă e mereu aceeași: ce s-a schimbat și când? Cu un istoric complet al lansărilor, răspunsul vine în câteva secunde. Te uiți pe cronologie, vezi lansările și fie găsești o cauză plauzibilă, fie elimini o categorie întreagă de cauze. Fără registru, aceeași întrebare ajunge la ghicit și la memorie, și amândouă slăbesc pe măsură ce trece timpul.
Revenirea la versiunea anterioară durează un minut, nu o seară întreagă
Orice lansare poate fi anulată cu un singur clic. Pentru că o lansare e o unitate completă, cu istoric, nu o grămadă de fișiere modificate, revenirea nu înseamnă să reconstruiești cum arăta site-ul înainte. Înseamnă să alegi versiunea care rula până atunci și să o pui la loc.
O revenire ieftină schimbă toată psihologia lansărilor. Când revenirea e scumpă, fiecare lansare vine cu o apăsare nespusă: dacă am greșit ceva, ne așteaptă o noapte lungă. Echipele reacționează previzibil la apăsarea asta. Lansează mai rar, îngrămădesc mai multe modificări în fiecare lansare, iar fiecare lansare devine mai mare și mai riscantă, ceea ce apasă și mai tare. E un cerc vicios.
Când revenirea durează un minut, cercul se învârte invers. Lansările pot fi mici, pentru că o lansare nu mai e un eveniment care trebuie să își justifice riscul. Lansările mici se verifică mai ușor, se validează mai ușor și se înțeleg mai ușor atunci când ceva chiar pare în neregulă. Plasa de siguranță nu ajută doar în ziua rară în care ai nevoie de ea. Ea dă forma fiecărei lansări care nu ajunge niciodată să aibă nevoie de ea.
Lansările stau la coadă în loc să se ciocnească
O problemă pe care am scos-o din calcul de la început, prin felul în care am proiectat platforma: două lansări pornite spre același mediu în același timp. La noi, lansările simultane către același mediu se așază la coadă și rulează una după alta. A doua așteaptă să se termine prima, în loc să se ia la întrecere cu ea.
Contează mai mult decât pare. O lansare e o succesiune de pași, iar două asemenea succesiuni care se întrepătrund pe același site pot lăsa în urmă o stare pe care n-a vrut-o niciuna dintre lansări și pe care nimeni n-o poate explica ușor. Când platforma refuză pur și simplu să lase asta să se întâmple, e un răspuns mult mai bun decât să rogi oamenii să se coordoneze pe chat și să speri că iese bine. Mașinile se pricep să își aștepte rândul. Regulile care se bazează pe faptul că oamenii nu se vor ciocni niciodată nu sunt reguli cu adevărat.
Plictiseala se pregătește cu mult înainte de ziua lansării
Partea cea mai liniștită a lansărilor noastre nu ține, de fapt, de instrumente. Ține de faptul că, până să plece în lume, orice funcționalitate a rulat deja pe aceeași platformă pe care o va găsi în producție. În timpul dezvoltării rulăm local exact configurația de producție: aceleași containere securizate, aceeași configurație de server web, inclusiv TLS. Mediul în care e construită o funcționalitate se comportă ca mediul în care va trăi.
Din experiența noastră, o mare parte din drama lansărilor e, de fapt, dramă de mediu. Codul era bun; locul în care a ajuns era altul decât cel în care a fost scris. Când închizi distanța asta, dispare o întreagă specie de surprize înainte să apuce să existe. Pentru ziua lansării rămâne setul mic și bine cunoscut de pași pe care platforma îi execută la fel, de fiecare dată.
Ce înseamnă asta dacă e site-ul tău
Mai tot ce am descris e mașinărie de care un client nu se atinge niciodată, și exact ăsta e rostul. La tine ajunge rezultatul. Modificările site-ului tău intră live când au fost planificate să intre, nu când se aliniază astrele. Poți vedea istoricul lansărilor, ce a intrat live și când, pe înțelesul oricui, în același portal unde trăiește restul proiectului tău. Iar dacă ceva nu e în regulă la o lansare, revii la starea de dinainte într-un minut, nu într-o seară întreagă, și în niciun caz nu ajungi la o pagină de mentenanță.
Mai e și un câștig mai discret, pe termen lung. Un site cu lansări ieftine și sigure e îmbunătățit mai des. Ideile mici ajung live pentru că publicarea lor nu e un spectacol întreg. În câțiva ani, șirul ăsta constant de îmbunătățiri mici adună mai mult decât orice reconstrucție mare, iar site-ul nu trebuie să își țină respirația pe drum.
Reușita e când nu se întâmplă nimic
Nimeni nu scrie studii de caz despre lansări în care nu s-a întâmplat nimic. Dar lansarea în care nu s-a întâmplat nimic e produsul fiecărei decizii luate înaintea ei: lansarea explicită, istoricul înregistrat, revenirea cu un singur clic, coada care previne ciocnirile, mediul de dezvoltare identic cu producția. Scoate oricare dintre ele și nu te mai poți bizui pe liniște la fel.
Noi o vedem așa: emoțiile dintr-un proces de lansare sunt un cost pe care cineva îl plătește până la urmă, de obicei în cel mai prost moment posibil. Așa că ne investim efortul în lansări fără surprize și considerăm fiecare zi de lansare plictisitoare o mică reușită de inginerie care face exact ce a fost construită să facă.