La GitLab, procesăm corecțiile software în două moduri: manual și automat. Citiți mai departe pentru a afla despre munca managerului de lansare de a crea și furniza actualizări importante prin implementare automată pe gitlab.com, precum și corecții cu care utilizatorii pot lucra la propriile instalări.
Recomand să setați un memento pe ceasul dvs. inteligent: în fiecare lună, pe 22, utilizatorii care lucrează cu GitLab la unitățile lor pot vedea actualizări ale versiunii curente a produsului nostru. Versiunea lunară conține caracteristici noi, dezvoltări ale celor existente și arată adesea rezultatul final al solicitărilor comunității pentru instrumente sau fuziuni.
Dar, după cum arată practica, dezvoltarea software-ului este rareori fără defecte. Când se descoperă o eroare sau o vulnerabilitate de securitate, managerul de lansare din echipa de livrare creează un patch pentru utilizatorii noștri cu instalările lor. Gitlab.com este actualizat în timpul procesului de CD. Numim acest proces CD implementare automată pentru a evita confuzia cu caracteristica CD din GitLab. Acest proces poate încorpora sugestii din solicitările de extragere trimise de utilizatori, clienți și echipa noastră de dezvoltare internă, astfel încât rezolvarea problemei plictisitoare a eliberării de patch-uri să fie rezolvată în două moduri foarte diferite.
«Ne asigurăm că tot ceea ce fac dezvoltatorii este implementat în toate mediile în fiecare zi înainte de a-l lansa pe GitLab.com", explică , Director Tehnic Superior, Departamentul Infrastructură. "Gândiți-vă la versiunile pentru instalările dvs. ca instantanee pentru implementările gitlab.com, pentru care am adăugat pași separați pentru a crea un pachet, astfel încât utilizatorii noștri să-l poată utiliza pentru a-l instala pe instalațiile lor".
Indiferent de eroare sau vulnerabilitate, clienții gitlab.com vor primi remedieri la scurt timp după ce au fost publicate, ceea ce este un beneficiu al procesului automat de CD. Patch-urile pentru utilizatorii cu propriile lor instalări necesită pregătire separată de către managerul de versiuni.
Echipa de livrare lucrează din greu pentru a automatiza majoritatea proceselor implicate în crearea versiunilor de reducere (timpul mediu până la producție, adică timpul petrecut în producție), perioada de timp de la procesarea unei cereri de îmbinare de către un dezvoltator până la implementarea pe gitlab.com.
«Scopul echipei de livrare este să ne asigurăm că ne putem deplasa mai repede ca companie sau cel puțin să îi facem pe cei care livrează să lucreze mai repede, corect?, spune Marin.
Atât clienții gitlab.com, cât și utilizatorii instalațiilor lor beneficiază de eforturile echipei de livrare de a reduce timpii de ciclu și de a accelera implementările. În acest articol vom explica asemănările și diferențele dintre aceste două metode. , și vom descrie, de asemenea, modul în care echipa noastră de livrare pregătește patch-uri pentru utilizatorii care lucrează la facilitățile lor, precum și cum ne asigurăm că gitlab.com este actualizat folosind implementarea automată.
Ce face un manager de lansare?
Membrii echipei lunar lansările noastre către utilizatori la unitățile lor, inclusiv patch-uri și versiuni de securitate care pot apărea între versiuni. Ei sunt, de asemenea, responsabili pentru conducerea tranziției companiei către implementare automată și continuă.
Versiunile cu autoinstalare și versiunile gitlab.com folosesc fluxuri de lucru similare, dar rulează în momente diferite, explică Marin.
În primul rând, managerul de lansare, indiferent de tipul de lansare, se asigură că GitLab este disponibil și securizat din momentul lansării aplicației pe gitlab.com, inclusiv asigurându-se că aceleași probleme nu ajung în infrastructura clienților cu propriile capacitati.
Odată ce o eroare sau o vulnerabilitate este marcată ca remediată în GitLab, managerul de lansare trebuie să evalueze că va fi inclusă în corecțiile sau actualizările de securitate pentru utilizatorii cu instalările lor. Dacă decide că un bug sau o vulnerabilitate merită o actualizare, începe munca pregătitoare.
Managerul de lansare trebuie să decidă dacă să pregătească o remediere sau când să o implementeze - iar acest lucru depinde în mare măsură de contextul situației.Între timp, mașinile nu sunt la fel de bune în gestionarea contextului ca oamenii", spune Marin.
Totul ține de remedieri
Ce sunt patch-urile și de ce avem nevoie de ele?
Managerul de versiuni decide dacă să lanseze o remediere în funcție de gravitatea erorii.
Erorile variază în funcție de gravitatea lor. Deci erorile S4 sau S3 pot fi stilistice, cum ar fi deplasarea pixelilor sau a pictogramei. Acest lucru nu este mai puțin important, dar nu există un impact semnificativ asupra fluxului de lucru al nimănui, ceea ce înseamnă că probabilitatea ca o remediere să fie creată pentru astfel de erori S3 sau S4 este mică, explică Marin.
Cu toate acestea, vulnerabilitățile S1 sau S2 înseamnă că utilizatorul nu ar trebui să se actualizeze la cea mai recentă versiune sau există o eroare semnificativă care afectează fluxul de lucru al utilizatorului. Dacă sunt incluse în tracker, mulți utilizatori le-au întâlnit, așa că managerul de lansare începe imediat să pregătească o remediere.
Odată ce un patch pentru vulnerabilitățile S1 sau S2 este gata, managerul de lansare începe să lanseze patch-ul.
De exemplu, patch-ul GitLab 12.10.1 a fost creat după ce au fost identificate mai multe probleme de blocare, iar dezvoltatorii au remediat problema de bază care le-a cauzat. Managerul de lansare a evaluat corectitudinea nivelurilor de severitate atribuite și, după confirmare, a fost lansat procesul de eliberare a unei remedieri, care a fost gata în XNUMX de ore de la descoperirea problemelor de blocare.
Când se acumulează o mulțime de S4, S3 și S2, managerul de lansare se uită la context pentru a determina urgența lansării unei corecții, iar când se ajunge la un anumit număr dintre ele, toate sunt combinate și eliberate. Remedierile ulterioare lansării sau actualizările de securitate sunt rezumate în postările de blog.
Cum un manager de lansare creează patch-uri
Folosim GitLab CI și alte funcții precum ChatOps pentru a genera patch-uri. Managerul de lansare începe lansarea remedierii activând echipa ChatOps pe canalul nostru intern #releases în Slack.
/chatops run release prepare 12.10.1ChatOps funcționează în Slack pentru a declanșa diferite evenimente, care sunt apoi procesate și executate de GitLab. De exemplu, echipa de livrare a configurat ChatOps pentru a automatiza diverse lucruri pentru a lansa patch-uri.
Odată ce managerul de lansare pornește echipa ChatOps în Slack, restul lucrării are loc automat în GitLab folosind CICD. Există o comunicare bidirecțională între ChatOps în Slack și GitLab în timpul procesului de lansare, deoarece managerul de lansare activează unii dintre pașii majori ai procesului.
Videoclipul de mai jos arată procesul tehnic de pregătire a unui patch pentru GitLab.
Cum funcționează implementarea automată pe gitlab.com
Procesul și instrumentele folosite pentru a actualiza gitlab.com sunt similare cu cele folosite pentru a crea patch-uri. Actualizarea gitlab.com necesită mai puțină muncă manuală din punctul de vedere al managerului de versiuni.
În loc să rulăm implementări folosind ChatOps, folosim funcții CI, de ex. , cu care managerul de lansări poate programa anumite acțiuni care urmează să fie efectuate la momentul necesar. În loc de un proces manual, există o conductă care rulează periodic o dată pe oră, care descarcă noile modificări aduse proiectelor GitLab, le împachetează și programează implementarea și rulează automat testarea, QA și alți pași necesari.
„Așadar, avem o mulțime de implementări care rulează în diferite medii înainte de gitlab.com și, după ce mediile respective sunt într-o formă bună și testele arată rezultate bune, managerul de lansare începe acțiunile de implementare a gitlab.com”, spune Marin.
Tehnologia CICD pentru susținerea actualizărilor gitlab.com automatizează întregul proces până la punctul în care managerul de lansare trebuie să lanseze manual implementarea mediului de producție pe gitlab.com.
Marin intră în detalii despre procesul de actualizare a gitlab.com în videoclipul de mai jos.
Ce altceva mai face echipa de livrare?
Principala diferență dintre procesele de actualizare gitlab.com și lansarea de corecții către clienți în interior este că acest din urmă proces necesită mai mult timp și mai multă muncă manuală din partea managerului de lansare.
„Uneori amânăm lansarea de patch-uri către clienți cu instalările lor din cauza problemelor raportate, problemelor legate de instrumente și pentru că există multe nuanțe care trebuie luate în considerare atunci când lansăm un singur patch”, spune Marin.
Unul dintre obiectivele pe termen scurt ale echipei de livrare este reducerea volumului de muncă manuală din partea managerului de eliberare pentru a accelera lansarea. Echipa lucrează pentru a simplifica, eficientiza și automatiza procesul de lansare, ceea ce va ajuta la remedierea problemelor de severitate scăzută (S3 și S4, aproximativ traducător). Concentrarea pe viteză este un indicator cheie de performanță: este necesar să se reducă MTTP - timpul de la primirea unei cereri de îmbinare până la implementarea rezultatului pe gitlab.com - de la 50 de ore actuale la 8 ore.
Echipa de livrare lucrează, de asemenea, la migrarea gitlab.com către o infrastructură bazată pe Kubernetes.
NB editorului: Dacă ați auzit deja despre tehnologia Kubernetes (și nu am nicio îndoială că ați făcut-o), dar nu ați atins-o încă cu mâinile, vă recomand să participați la cursuri intensive online , care va avea loc în perioada 28-30 septembrie, și , care va avea loc în perioada 14–16 octombrie. Acest lucru vă va permite să navigați cu încredere și să lucrați cu tehnologia.
Acestea sunt două abordări care urmăresc același scop: livrarea rapidă a actualizărilor, atât pentru gitlab.com, cât și pentru clienții de la unitățile lor.
Ceva idei sau recomandari pentru noi?
Toată lumea este binevenită să contribuie la GitLab și salutăm feedback-ul cititorilor noștri. Dacă aveți idei pentru echipa noastră de livrare, nu ezitați cu preaviz team: Delivery.
Sursa: www.habr.com