Lansarea unei noi versiuni a proiectului în producție necesită respectarea atentă a echilibrului între viteza desfășurării și fiabilitatea soluției. La Slack, se apreciază iterațiile rapide, ciclurile scurte de feedback și reacția rapidă la solicitările utilizatorilor. În plus, compania dispune de sute de programatori care își doresc maximă productivitate.
Autorii materialului, traducerea căruia o publicăm astăzi, afirmă că o companie care aspiră să respecte astfel de valori și în același timp se dezvoltă, trebuie să îmbunătățească în mod constant sistemul său de desfășurare a proiectelor. Compania trebuie să investească în transparența și fiabilitatea proceselor de lucru, pentru a se asigura că acestea sunt proporționale cu dimensiunea proiectului. Aici va fi vorba despre procesele de lucru dezvoltate în Slack și despre unele soluții care au condus compania să utilizeze astăzi sistemul existent de desfășurare a proiectelor.
Cum funcționează astăzi procesele de desfășurare a proiectelor
Fiecare PR (pull request) în Slack trebuie să fie supus în mod obligatoriu unei revizii de cod și să treacă cu succes toate testele. Numai după ce aceste condiții sunt îndeplinite, programatorul poate face fuziunea codului său cu ramura master a proiectului. Totuși, desfășurarea acestui cod are loc doar în orele de lucru conform fusului orar nord-american. Prin urmare, având în vedere că angajații noștri sunt la locurile de muncă, suntem complet pregătiți pentru a rezolva orice probleme neașteptate.
În fiecare zi, efectuăm aproximativ 12 desfășurări planificate. În timpul fiecărei desfășurări, programatorul desemnat ca responsabil de desfășurare este responsabil pentru lansarea noii versiuni în producție. Acesta este un proces în mai mulți pași care asigură o trecere lină a versiunii în modul de lucru. Datorită acestui abordări, putem identifica erorile înainte ca acestea să afecteze toți utilizatorii noștri. Dacă se descoperă prea multe erori, desfășurarea versiunii poate fi anulată. Dacă o problemă specifică este identificată după lansare, poate fi emisă o corectare cu ușurință.
Interfața sistemului Checkpoint, utilizată în Slack pentru desfășurarea proiectelor
Procesul de desfășurare a unei noi versiuni în producție poate fi reprezentat prin patru pași.
▍1. Crearea unei ramuri de versiune
Fiecare versiune începe cu o nouă ramură de versiune, de la un moment din istoria noastră Git. Aceasta permite atribuirea de etichete versiunii și oferă un loc unde pot fi aplicate corecturile rapide pentru erorile descoperite în timpul pregătirii versiunii pentru lansare în producție.
▍2. Desfășurarea în mediu intermediar
Următorul pas în proces este desfășurarea construcției pe serverele intermediare (staging) și executarea testului automatizat pentru verificarea funcționalității generale a proiectului (smoke test). Mediu intermediar este un mediu de producție care nu primește trafic extern. În acest mediu, efectuăm teste manuale suplimentare. Acest lucru ne oferă o siguranță suplimentară că proiectul modificat funcționează corect. Doar testele automatizate nu sunt suficiente pentru a obține o asemenea siguranță.
▍3. Desfășurarea în medii dogfood și canary
Desfășurarea în producție începe cu mediu dogfood, reprezentat de un set de gazde care asigură spațiile noastre de lucru interne Slack. Fiind utilizatori destul de activi ai Slack, aplicarea acestei abordări ne-a ajutat să descoperim numeroase erori în stadii incipiente ale desfășurării. După ce ne-am asigurat că funcționalitatea de bază a sistemului nu este afectată, desfășurăm construcția în mediu canary. Acesta reprezintă sistemele care primesc aproximativ 2% din trafic de producție.
▍4. Trecerea treptată în producție
Dacă indicatorii de monitorizare ai noii versiuni se dovedesc a fi stabili, iar după desfășurarea proiectului în mediu canary nu primim plângeri, continuăm trecerea treptată a serverelor de producție la noua versiune. Procesul de desfășurare este împărțit în etape: 10%, 25%, 50%, 75% și 100%. Ca rezultat, putem transfera încet traficul de producție către noua versiune a sistemului. În acest fel, avem timp să investigăm situația în cazul în care se descoperă anomalii.
▍Ce să facem dacă ceva a mers prost în timpul desfășurării?
Modificările codului sunt întotdeauna riscante. Dar facem față acestei provocări datorită «responsabililor de desfășurare» bine pregătiți, care coordonează procesul de lansare a noilor versiuni în producție, monitorizează indicatorii și coordonează activitatea programatorilor care lansează cod.
În cazul în care ceva a mers greșit, încercăm să identificăm problema cât mai repede posibil. Investigăm problema, găsim PR-ul care cauzează erorile, îl respingem, analizăm cu atenție și creăm o nouă versiune. Totuși, uneori problema rămâne nedetectată până la lansarea proiectului în producție. În această situație, cel mai important lucru este să restabilim funcționarea serviciului. Prin urmare, înainte de a începe investigația problemei, revenim imediat la cea mai recentă versiune care a funcționat.
Modulele sistemului de desfășurare
Să analizăm tehnologiile care stau la baza sistemului nostru de desfășurare a proiectelor.
▍Desfășurări rapide
Procesele de lucru descrise mai sus pot părea, în retrospectivă, complet evidente. Dar sistemul nostru de desfășurare nu a ajuns la acest punct imediat.
Când compania era mult mai mică, întregul nostru aplicație putea funcționa pe 10 instanțe Amazon EC2. Desfășurarea unui proiect în această situație însemna utilizarea rsync pentru sincronizarea rapidă a tuturor serverelor. Anterior, noul cod era separat de producție doar printr-un singur pas, reprezentat de un mediu intermediar. Versiunile erau create și testate în acest mediu, apoi mergeau direct în producție. Era foarte simplu să înțelegi un astfel de sistem, permitea oricărui programator să desfășoare codul scris de el oricând.
Dar pe măsură ce numărul clienților a crescut, a crescut și dimensiunea infrastructurii necesare pentru a susține proiectul. Curând, în contextul creșterii constante a sistemului, modelul nostru de desfășurare, bazat pe trimiterea de cod nou pe servere, a început să nu mai funcționeze. Anume, adăugarea fiecărui nou server a dus la creșterea timpului necesar pentru desfășurare. Chiar și strategiile bazate pe aplicarea paralelă a rsync au anumite limitări.
În cele din urmă, am rezolvat această problemă trecând la un sistem de desfășurare complet paralel, structurat diferit față de vechiul sistem. Mai precis, acum nu mai trimiteam cod pe servere folosind scripturi de sincronizare. Fiecare server descărca acum singur noua versiune, aflând că trebuie să o facă prin monitorizarea modificării cheii Consul. Serverele descărcau codul în paralel. Acest lucru ne-a permis să menținem o viteză mare de desfășurare chiar și în condițiile unei creșteri constante a sistemului.
1. Serverele de producție monitorizează cheia Consul. 2. Cheia se schimbă, comunicând serverelor că trebuie să înceapă descărcarea noului cod. 3. Serverele descarcă fișierele tarball cu codul aplicației.
▍Desfășurări atomice
O altă soluție care ne-a ajutat să ajungem la un sistem de desfășurare multi-nivel a fost desfășurarea atomică.
Până la utilizarea desfășurărilor atomice, fiecare desfășurare putea duce la apariția unui număr mare de mesaje de eroare. Asta se datora faptului că procesul de copiere a fișierelor noi pe serverele de producție nu eraatomic. Aceasta ducea la existența unei perioade scurte de timp în care codul care apelase funcții noi devenea disponibil înainte ca aceste funcții să fie accesibile. Când un astfel de cod era apelat, acesta conducea la returnarea unor erori interne. Acest lucru se manifesta prin cereri nereușite la API și prin pagini web "stricate".
Echipa care s-a ocupat de această problemă a rezolvat-o introducând conceptele de directorii "calde" (hot) și "reci" (cold). Codul din directorul "cald" se ocupă de gestionarea traficului de producție. În directorii "reci", codul se pregătește pentru utilizare în timpul funcționării sistemului. În timpul desfășurării, noul cod este copiat în directorul "rece" neutilizat. Apoi, când pe server nu mai există procese active, se face un switch instantaneu între directoare.
1. Dezarhivarea codului aplicației în directorul "rece". 2. Schimbarea sistemului pe directorul "rece", care devine "cald" (operație atomică)
Concluzii: accentul pe fiabilitate
În 2018, proiectul a crescut atât de mult încât desfășurarea rapidă a început să afecteze stabilitatea produsului. Am avut un sistem de desfășurare destul de avansat, în care am investit multă muncă și timp. Trebuia doar să reorganizăm și să îmbunătățim procesele de organizare a desfășurării. Ne-am transformat într-o companie destul de mare, iar soluțiile noastre erau utilizate în întreaga lume pentru a asigura comunicații neîncetate și pentru a rezolva probleme importante. De aceea, fiabilitatea a devenit centrul atenției noastre.
Trebuia să facem procesul de desfășurare a noilor versiuni Slack mai sigur. Această necesitate ne-a condus la îmbunătățirea sistemului nostru de desfășurare. De fapt, despre acest sistem îmbunătățit am discutat mai sus. În adâncurile sistemului, continuăm să folosim tehnologii de desfășurare rapidă și atomică. S-a schimbat modul în care se desfășoară desfășurarea. Noua noastră sistemă este destinată desfășurării gradate a noului cod la diferite niveluri, în diferite medii. Acum folosim instrumente auxiliare și instrumente de monitorizare mai avansate decât înainte. Aceasta ne oferă posibilitatea de a captura și remedia erorile cu mult înainte ca ele să ajungă la utilizatorul final.
Dar nu ne oprim aici. Îmbunătățim constant acest sistem, aplicând instrumente auxiliare și soluții de automatizare mai avansate.
Stimați cititori! Cum este organizat procesul de desfășurare a noilor versiuni ale proiectelor acolo unde lucrați dumneavoastră?
Sursa: habr.com
