Introducerea în producție a unui nou proiect necesită un echilibru atent între viteza de implementare și fiabilitatea soluției. Slack valorează iterațiile rapide, ciclurile scurte de feedback și răspunsul prompt la solicitările utilizatorilor. În plus, compania are sute de programatori care se străduiesc să fie cât mai productivi.
Autorii materialului, a cărui traducere o publicăm astăzi, spun că o companie care se străduiește să adere la astfel de valori și în același timp crește trebuie să își îmbunătățească constant sistemul de implementare a proiectelor. Compania trebuie să investească în transparența și fiabilitatea proceselor de lucru, făcând acest lucru pentru a se asigura că aceste procese corespund dimensiunii proiectului. Aici vom vorbi despre fluxurile de lucru care s-au dezvoltat în Slack și despre unele dintre deciziile care au determinat compania să utilizeze sistemul de implementare a proiectelor care există astăzi.
Cum funcționează procesele de implementare a proiectelor astăzi
Fiecare PR (pull request) din Slack trebuie să facă obiectul revizuirii codului și trebuie să treacă cu succes toate testele. Numai după ce aceste condiții sunt îndeplinite, programatorul își poate îmbina codul în ramura principală a proiectului. Cu toate acestea, acest cod este implementat numai în timpul programului de lucru, ora Americii de Nord. Drept urmare, datorită faptului că angajații noștri se află la locurile lor de muncă, suntem pe deplin pregătiți să rezolvăm orice problemă neașteptată.
În fiecare zi, efectuăm aproximativ 12 implementări planificate. În timpul fiecărei implementări, programatorul desemnat ca lider de implementare este responsabil pentru introducerea noii versiuni în producție. Acesta este un proces în mai multe etape care asigură ca ansamblul să fie introdus fără probleme în producție. Datorită acestei abordări, putem detecta erori înainte ca acestea să afecteze toți utilizatorii noștri. Dacă există prea multe erori, implementarea ansamblului poate fi anulată. Dacă o anumită problemă este descoperită după lansare, o remediere poate fi lansată cu ușurință pentru aceasta.
Interfața sistemului Checkpoint, care este utilizată în Slack pentru implementarea proiectelor
Procesul de implementare a unei noi versiuni în producție poate fi considerat ca fiind format din patru pași.
▍1. Crearea unei ramuri de lansare
Fiecare lansare începe cu o nouă ramură de lansare, un punct din istoria noastră Git. Acest lucru vă permite să atribuiți etichete versiunii și oferă un loc în care puteți face remedieri live pentru erorile găsite în procesul de pregătire a versiunii pentru lansarea în producție.
▍2. Implementare într-un mediu de staging
Următorul pas este să implementezi ansamblul pe servere de staging și să rulezi un test automat pentru performanța globală a proiectului (test de fum). Mediul de pregătire 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 încredere suplimentară că proiectul modificat funcționează corect. Numai testele automate nu sunt suficiente pentru a oferi acest nivel de încredere.
▍3. Implementare în medii testate și canare
Implementarea în producție începe cu un mediu de testare, reprezentat de un set de gazde care deservesc spațiile noastre interne de lucru Slack. Deoarece suntem utilizatori Slack foarte activi, adoptarea acestei abordări ne-a ajutat să detectăm o mulțime de erori la începutul implementării. După ce ne-am asigurat că funcționalitatea de bază a sistemului nu este ruptă, ansamblul este desfășurat în mediul canar. Reprezintă sisteme care reprezintă aproximativ 2% din traficul de producție.
▍4. Lansare treptată în producție
Dacă indicatorii de monitorizare pentru noua versiune se dovedesc stabili și dacă după implementarea proiectului în mediul canar nu am primit reclamații, continuăm să transferăm treptat serverele de producție pe noua versiune. Procesul de implementare este împărțit în următoarele etape: 10%, 25%, 50%, 75% și 100%. Drept urmare, putem transfera încet traficul de producție către noua versiune a sistemului. În același timp, avem timp să investigăm situația dacă sunt detectate anomalii.
▍Ce se întâmplă dacă ceva nu merge bine în timpul implementării?
A face modificări la cod este întotdeauna un risc. Dar facem față acestui lucru datorită prezenței unor „lideri de implementare” bine pregătiți, care gestionează procesul de introducere a unei noi versiuni în producție, monitorizează indicatorii de monitorizare și coordonează munca programatorilor care lansează cod.
În cazul în care ceva nu merge cu adevărat bine, încercăm să detectăm problema cât mai curând posibil. Investigăm problema, găsim PR-ul care provoacă erorile, îl derulăm înapoi, îl analizăm în detaliu și creăm o nouă versiune. Adevărat, uneori problema trece neobservată până când proiectul intră în producție. Într-o astfel de situație, cel mai important lucru este restabilirea serviciului. Prin urmare, înainte de a începe să investigăm problema, revenim imediat la versiunea anterioară de lucru.
Elementele de bază ale unui sistem de implementare
Să ne uităm la tehnologiile care stau la baza sistemului nostru de implementare a proiectelor.
▍Implementări rapide
Fluxul de lucru descris mai sus poate părea, retrospectiv, oarecum evident. Dar sistemul nostru de implementare nu a devenit astfel imediat.
Când compania era mult mai mică, întreaga noastră aplicație putea rula pe 10 instanțe Amazon EC2. Implementarea proiectului în această situație a însemnat utilizarea rsync pentru a sincroniza rapid toate serverele. Anterior, noul cod era la doar un pas de producție, reprezentat de un mediu de organizare. Ansamblurile au fost create și testate într-un astfel de mediu, apoi au trecut direct în producție. A fost foarte ușor de înțeles un astfel de sistem; a permis oricărui programator să implementeze codul pe care îl scrisese în orice moment.
Dar pe măsură ce numărul clienților noștri a crescut, la fel a crescut și amploarea infrastructurii necesare pentru a susține proiectul. Curând, având în vedere creșterea constantă a sistemului, modelul nostru de implementare, bazat pe împingerea codului nou către servere, nu și-a mai făcut treaba. Și anume, adăugarea fiecărui server nou a însemnat creșterea timpului necesar pentru finalizarea implementării. Chiar și strategiile bazate pe utilizarea paralelă a rsync au anumite limitări.
Am ajuns să rezolvăm această problemă trecând la un sistem de implementare complet paralel, care a fost proiectat diferit de vechiul sistem. Și anume, acum nu am trimis cod către servere folosind un script de sincronizare. Acum fiecare server a descărcat independent noul ansamblu, știind că trebuie să facă acest lucru prin monitorizarea schimbării cheii Consul. Serverele au încărcat codul în paralel. Acest lucru ne-a permis să menținem o viteză mare de implementare chiar și într-un mediu de creștere constantă a sistemului.
1. Serverele de producție monitorizează cheia Consul. 2. Cheia se schimbă, aceasta le spune serverelor că trebuie să înceapă descărcarea codului nou. 3. Serverele descarcă fișiere tarball cu codul aplicației
▍Implementări atomice
O altă soluție care ne-a ajutat să ajungem la un sistem de implementare cu mai multe niveluri a fost implementarea atomică.
Înainte de a utiliza implementările atomice, fiecare implementare poate avea ca rezultat un număr mare de mesaje de eroare. Faptul este că procesul de copiere a fișierelor noi pe serverele de producție nu a fost atomic. Acest lucru a dus la o fereastră scurtă de timp în care codul care a numit funcții noi a fost disponibil înainte ca funcțiile în sine să fie disponibile. Când a fost apelat un astfel de cod, a avut ca rezultat returnarea erorilor interne. Acest lucru s-a manifestat în solicitări API nereușite și pagini web sparte.
Echipa care a lucrat la această problemă a rezolvat-o prin introducerea conceptului de directoare „fierbinte” și „rece”. Codul din directorul fierbinte este responsabil pentru procesarea traficului de producție. Și în directoarele „rece”, codul, în timp ce sistemul rulează, este doar pregătit pentru utilizare. În timpul implementării, codul nou este copiat într-un director rece neutilizat. Apoi, când nu există procese active pe server, se efectuează o schimbare instantanee a directorului.
1. Despachetarea codului aplicației într-un director „rece”. 2. Trecerea sistemului la un director „rece”, care devine „fierbinte” (operare atomică)
Rezultate: schimbarea accentului pe fiabilitate
În 2018, proiectul a crescut la o astfel de scară încât implementarea foarte rapidă a început să afecteze stabilitatea produsului. Aveam un sistem de implementare foarte avansat în care am investit mult timp și efort. Tot ce trebuia să facem a fost să reconstruim și să ne îmbunătățim procesele de implementare. Am devenit o companie destul de mare, ale cărei dezvoltări au fost folosite în întreaga lume pentru a organiza comunicații neîntrerupte și pentru a rezolva probleme importante. Prin urmare, fiabilitatea a devenit în centrul atenției noastre.
Trebuia să facem procesul de implementare a noilor versiuni Slack mai sigur. Această nevoie ne-a determinat să ne îmbunătățim sistemul de implementare. De fapt, am discutat mai sus despre acest sistem îmbunătățit. În adâncurile sistemului, continuăm să folosim tehnologii de implementare rapidă și atomică. Modul în care se face implementarea s-a schimbat. Noul nostru sistem este conceput pentru a implementa treptat cod nou la diferite niveluri, în diferite medii. Acum folosim instrumente de asistență mai avansate și instrumente de monitorizare a sistemului decât înainte. Acest lucru ne oferă posibilitatea de a detecta și remedia erorile cu mult înainte ca acestea să aibă șansa de a ajunge la utilizatorul final.
Dar nu ne vom opri aici. Îmbunătățim constant acest sistem, folosind instrumente auxiliare mai avansate și instrumente de automatizare a muncii.
Dragi cititori! Cum funcționează procesul de implementare a noilor versiuni de proiect acolo unde lucrați?
Sursa: www.habr.com