U GitLabu softverske popravke obrađujemo na dva načina: ručno i automatski. Čitajte dalje kako biste saznali više o poslu upravitelja izdanja stvaranja i isporuke važnih ažuriranja putem automatizirane implementacije na gitlab.com, kao i o zakrpama s kojima korisnici mogu raditi na svojim instalacijama.
Preporučujem da postavite podsjetnik na svom pametnom satu: svakog 22. mjeseca, korisnici koji rade s GitLabom u svojim objektima mogu vidjeti ažuriranja trenutne verzije našeg proizvoda. Mjesečno izdanje sadrži nove značajke, razvoj postojećih i često prikazuje krajnji rezultat zahtjeva zajednice za alatima ili spajanjima.
Ali, kao što praksa pokazuje, razvoj softvera rijetko je bez nedostataka. Kada se otkrije bug ili sigurnosna ranjivost, upravitelj izdanja u timu za isporuku stvara zakrpu za naše korisnike s njihovim instalacijama. Gitlab.com se ažurira tijekom procesa CD-a. Taj proces CD-a nazivamo automatskom implementacijom kako bismo izbjegli zabunu sa značajkom CD-a u GitLabu. Ovaj proces može uključiti prijedloge iz zahtjeva za povlačenjem koje su podnijeli korisnici, kupci i naš interni razvojni tim, tako da se rješavanje dosadnog problema izdavanja zakrpa rješava na dva vrlo različita načina.
«Osiguravamo da sve što razvojni programeri naprave bude implementirano u sva okruženja svaki dan prije nego što to objavimo na GitLab.com“, objašnjava , viši tehnički voditelj, Odjel za infrastrukturu. "Zamislite izdanja za svoje instalacije kao snimke za gitlab.com implementacije, za koje smo dodali zasebne korake za izradu paketa tako da ga naši korisnici mogu koristiti za instalaciju na svojim instalacijama".
Bez obzira na grešku ili ranjivost, korisnici gitlab.com će primiti popravke ubrzo nakon što budu objavljeni, što je prednost automatiziranog procesa CD-a. Zakrpe za korisnike s vlastitim instalacijama zahtijevaju posebnu pripremu od strane upravitelja izdanja.
Tim za isporuku naporno radi na automatizaciji većine procesa uključenih u stvaranje izdanja za smanjenje (srednje vrijeme do proizvodnje, tj. vrijeme potrošeno na proizvodnju), vremensko razdoblje od obrade zahtjeva za spajanje od strane programera do implementacije na gitlab.com.
«Cilj tima za dostavu je osigurati da se možemo kretati brže kao tvrtka ili barem učiniti da dostavljači rade brže, zar ne?, kaže Marin.
I korisnici gitlab.com i korisnici njihovih instalacija imaju koristi od napora tima za isporuku da skrate vrijeme ciklusa i ubrzaju implementacije. U ovom ćemo članku objasniti sličnosti i razlike između ove dvije metode. , a također ćemo opisati kako naš tim za dostavu priprema zakrpe za korisnike koji rade na svojim objektima, kao i kako osiguravamo da je gitlab.com ažuran korištenjem automatizirane implementacije.
Što radi upravitelj izdanja?
Članovi tima mjesečno naša izdanja korisnicima u njihovim objektima, uključujući zakrpe i sigurnosna izdanja koja se mogu pojaviti između izdanja. Oni su također odgovorni za vođenje prijelaza tvrtke na automatiziranu, kontinuiranu implementaciju.
Izdanja za samoinstalaciju i izdanja gitlab.com koriste slične tijekove rada, ali se pokreću u različito vrijeme, objašnjava Marin.
Prvo i najvažnije, upravitelj izdanja, bez obzira na vrstu izdanja, osigurava da je GitLab dostupan i siguran od trenutka kada se aplikacija pokrene na gitlab.com, uključujući osiguravanje da isti problemi ne završe u infrastrukturi korisnika s njihovim vlastite kapacitete.
Nakon što je greška ili ranjivost označena kao ispravljena u GitLabu, upravitelj izdanja mora procijeniti hoće li biti uključena u zakrpe ili sigurnosna ažuriranja za korisnike s njihovim instalacijama. Ako odluči da bug ili ranjivost zaslužuje ažuriranje, počinje pripremni rad.
Upravitelj izdanja mora odlučiti hoće li pripremiti popravak ili kada ga implementirati - a to uvelike ovisi o kontekstu situacije, "u međuvremenu, strojevi nisu tako dobri u upravljanju kontekstom kao ljudi“ kaže Marin.
Sve je u popravcima
Što su zakrpe i zašto su nam potrebne?
Upravitelj izdanja odlučuje hoće li objaviti popravak na temelju ozbiljnosti greške.
Pogreške se razlikuju ovisno o njihovoj težini. Dakle, pogreške S4 ili S3 mogu biti stilske, poput pomaka piksela ili ikone. To nije ništa manje važno, ali nema značajnog utjecaja na bilo čiji tijek rada, što znači da je mala vjerojatnost da će se napraviti ispravak za takve S3 ili S4 greške, objašnjava Marin.
Međutim, ranjivosti S1 ili S2 znače da korisnik ne bi trebao izvršiti ažuriranje na najnoviju verziju ili postoji značajna pogreška koja utječe na tijek rada korisnika. Ako su uključeni u tracker, mnogi su se korisnici susreli s njima, pa upravitelj izdanja odmah počinje s pripremom popravka.
Nakon što je zakrpa za ranjivosti S1 ili S2 spremna, upravitelj izdanja počinje izdavati zakrpu.
Na primjer, zakrpa GitLab 12.10.1 stvorena je nakon što je identificirano nekoliko problema s blokiranjem i programeri su popravili temeljni problem koji ih je uzrokovao. Release manager procijenio je ispravnost dodijeljenih razina ozbiljnosti, a nakon potvrde pokrenut je proces izdavanja popravka koji je bio spreman unutar XNUMX sata nakon otkrivanja problema s blokiranjem.
Kada se nakupi puno S4, S3 i S2, upravitelj izdanja gleda kontekst kako bi odredio hitnost izdavanja popravka, a kada se dosegne određeni broj njih, svi se kombiniraju i puštaju. Popravci nakon izdanja ili sigurnosna ažuriranja sažeti su u postovima na blogu.
Kako upravitelj izdanja stvara zakrpe
Koristimo GitLab CI i druge značajke kao što je naš ChatOps za generiranje zakrpa. Upravitelj izdanja pokreće izdavanje popravka aktiviranjem ChatOps tima na našem internom kanalu #releases u Slacku.
/chatops run release prepare 12.10.1ChatOps radi unutar Slacka kako bi pokrenuo različite događaje, koje zatim obrađuje i izvršava GitLab. Na primjer, tim za dostavu postavio je ChatOps za automatizaciju raznih stvari za izdavanje zakrpa.
Nakon što upravitelj izdanja pokrene ChatOps tim u Slacku, ostatak posla odvija se automatski u GitLabu pomoću CICD-a. Postoji dvosmjerna komunikacija između ChatOpsa u Slacku i GitLaba tijekom procesa izdavanja jer upravitelj izdanja aktivira neke od glavnih koraka u procesu.
Video u nastavku prikazuje tehnički proces pripreme zakrpe za GitLab.
Kako funkcionira automatska implementacija na gitlab.com
Proces i alati koji se koriste za ažuriranje gitlab.com slični su onima koji se koriste za izradu zakrpa. Ažuriranje gitlab.com zahtijeva manje ručnog rada sa stajališta upravitelja izdanja.
Umjesto pokretanja implementacija pomoću ChatOps-a, koristimo CI značajke, npr. , s kojim upravitelj izdanja može zakazati određene radnje koje će se izvršiti u traženo vrijeme. Umjesto ručnog procesa, postoji cjevovod koji se pokreće periodički jednom na sat koji preuzima nove promjene napravljene na GitLab projektima, pakira ih i raspoređuje implementaciju te automatski pokreće testiranje, QA i druge potrebne korake.
"Dakle, imamo mnogo implementacija koje se izvode u različitim okruženjima prije gitlab.com, a nakon što su ta okruženja u dobrom stanju i testiranje pokaže dobre rezultate, upravitelj izdanja pokreće radnje implementacije gitlab.com", kaže Marin.
CICD tehnologija za podršku ažuriranjima gitlab.com automatizira cijeli proces do točke u kojoj upravitelj izdanja mora ručno pokrenuti implementaciju proizvodnog okruženja na gitlab.com.
Marin ide u detalje o procesu ažuriranja gitlab.com u videu ispod.
Što još radi dostavni tim?
Glavna razlika između procesa ažuriranja na gitlab.com i izdavanja zakrpa klijentima unutar tvrtke je u tome što potonji proces zahtijeva više vremena i više ručnog rada upravitelja izdanja.
"Ponekad odgađamo izdavanje zakrpa korisnicima s njihovim instalacijama zbog prijavljenih problema, problema s alatom i jer postoji mnogo nijansi koje treba uzeti u obzir prilikom izdavanja jedne zakrpe", kaže Marin.
Jedan od kratkoročnih ciljeva tima za isporuku je smanjiti količinu ručnog rada od strane upravitelja izdanja kako bi se ubrzalo izdavanje. Tim radi na pojednostavljenju, racionalizaciji i automatizaciji procesa izdavanja, što će pomoći u rješavanju problema niske ozbiljnosti (S3 i S4, cca. prevoditelj). Fokusiranje na brzinu ključni je pokazatelj učinka: potrebno je smanjiti MTTP - vrijeme od primanja zahtjeva za spajanje do postavljanja rezultata na gitlab.com - sa sadašnjih 50 sati na 8 sati.
Tim za isporuku također radi na migraciji gitlab.com na infrastrukturu temeljenu na Kubernetesu.
Bilješka urednika: Ako ste već čuli za Kubernetes tehnologiju (a ne sumnjam da jeste), ali je još niste dodirnuli rukama, preporučam sudjelovanje u online intenzivnim tečajevima , koji će se održati od 28. do 30. rujna i , koji će se održati od 14. do 16. listopada. To će vam omogućiti pouzdanu navigaciju i rad s tehnologijom.
Ovo su dva pristupa koji teže istom cilju: brza isporuka ažuriranja, kako za gitlab.com tako i za klijente u njihovim objektima.
Imate li ideja ili preporuka za nas?
Svatko je dobrodošao dati doprinos GitLabu i pozdravljamo povratne informacije naših čitatelja. Ako imate bilo kakvu ideju za naš tim za dostavu, ne oklijevajte uz obavijest team: Delivery.
Izvor: www.habr.com