U GitLabu obrađujemo softverske popravke na dva načina: ručno i automatski. Čitajte dalje kako biste saznali više o poslu upravitelja izdanja u kreiranju i isporuci važnih ažuriranja putem automatske implementacije na gitlab.com, kao i o zakrpama s kojima korisnici mogu raditi na vlastitim instalacijama.
Preporučujem da postavite podsjetnik na svoj pametni sat: svakog mjeseca 22., korisnici koji rade s GitLabom u svojim objektima mogu vidjeti ažuriranja trenutne verzije našeg proizvoda. Mjesečno izdanje sadrži nove funkcije, razvoj postojećih i često prikazuje krajnji rezultat zahtjeva zajednice za alate ili spajanja.
Ali, kako praksa pokazuje, razvoj softvera rijetko je bez nedostataka. Kada se otkrije greška ili sigurnosni propust, upravitelj izdanja u timu za isporuku kreira zakrpu za naše korisnike s njihovim instalacijama. Gitlab.com se ažurira tokom CD procesa. Ovaj CD proces nazivamo automatskom implementacijom kako bismo izbjegli zabunu sa CD funkcijom u GitLabu. Ovaj proces može uključiti prijedloge iz pull zahtjeva 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 programeri naprave bude raspoređeno u sva okruženja svaki dan prije nego što ga prenesemo na GitLab.com“, objašnjava , viši tehnički menadžer, odjel za infrastrukturu. "Razmišljajte o izdanjima za vaše instalacije kao o snimcima za implementacije gitlab.com, za koje smo dodali zasebne korake za kreiranje paketa kako bi ga naši korisnici mogli koristiti za instalaciju na svojim instalacijama".
Bez obzira na grešku ili ranjivost, korisnici gitlab.com će dobiti popravke ubrzo nakon što budu objavljeni, što je prednost automatizovanog CD procesa. 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 kreiranje izdanja za smanjenje (srednje vrijeme do proizvodnje, tj. vrijeme potrošeno na proizvodnju), vremenski period od obrade zahtjeva za spajanje od strane programera do implementacije na gitlab.com.
«Cilj tima za dostavu je osigurati da se možemo brže kretati kao kompanija, ili barem učiniti da dostavljači rade brže, zar ne?, kaže Marin.
I klijenti gitlab.com i korisnici njihovih instalacija imaju koristi od napora tima za isporuku da smanje vrijeme ciklusa i ubrza implementaciju. U ovom članku ćemo objasniti sličnosti i razlike između ove dvije metode. , a također ćemo opisati kako naš tim za isporuku priprema zakrpe za korisnike koji rade na svojim objektima, kao i kako osiguravamo da je gitlab.com ažuran korištenjem automatske implementacije.
Šta radi menadžer izdanja?
Članovi tima mjesečno naša izdanja za korisnike u njihovim objektima, uključujući zakrpe i sigurnosna izdanja koja se mogu pojaviti između izdanja. Oni su takođe odgovorni za vođenje tranzicije kompanije ka automatizovanoj, kontinuiranoj implementaciji.
Izdanja za samoinstalaciju i izdanja gitlab.com koriste slične tokove rada, ali se pokreću u različito vrijeme, objašnjava Marin.
Prije svega, 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 sa njihovim sopstvenim kapacitetima.
Kada se greška ili ranjivost označi kao popravljena u GitLabu, upravitelj izdanja mora procijeniti da li će biti uključeni u zakrpe ili sigurnosna ažuriranja za korisnike sa njihovim instalacijama. Ako odluči da greška ili ranjivost zaslužuju ažuriranje, počinje pripremni rad.
Upravitelj izdanja mora odlučiti hoće li pripremiti popravak ili kada će ga primijeniti - a to u velikoj mjeri ovisi o kontekstu situacije, "u međuvremenu, mašine nisu tako dobre u upravljanju kontekstom kao ljudi“, kaže Marin.
Sve se svodi na popravke
Šta su zakrpe i zašto su nam potrebne?
Upravitelj izdanja odlučuje hoće li objaviti ispravku na osnovu ozbiljnosti greške.
Greške se razlikuju ovisno o njihovoj ozbiljnosti. Dakle, greške S4 ili S3 mogu biti stilske, kao što je pomicanje piksela ili ikona. To nije ništa manje važno, ali nema značajnijeg utjecaja na ničiji radni tok, što znači da je mala vjerojatnost da će se napraviti popravak za takve S3 ili S4 greške, objašnjava Marin.
Međutim, ranjivosti S1 ili S2 znače da korisnik ne bi trebao ažurirati na najnoviju verziju ili postoji značajna greška koja utiče na radni tok korisnika. Ako su uključeni u tracker, mnogi korisnici su ih naišli, tako da upravitelj izdanja odmah počinje pripremati popravak.
Kada je zakrpa za ranjivosti S1 ili S2 spremna, upravitelj izdanja počinje izdavati zakrpu.
Na primjer, GitLab 12.10.1 zakrpa je kreirana nakon što je identificirano nekoliko problema s blokiranjem i programeri su popravili osnovni problem koji ih je uzrokovao. Release manager je procijenio ispravnost dodijeljenih nivoa ozbiljnosti i nakon potvrde pokrenut je proces puštanja popravka koji je bio spreman u roku od XNUMX sata nakon otkrivanja problema blokiranja.
Kada se akumulira puno S4, S3 i S2, upravitelj izdanja gleda u kontekst kako bi odredio hitnost izdavanja popravka, a kada se dostigne određeni broj njih, svi se kombinuju i puštaju. Ispravci nakon objavljivanja ili sigurnosna ažuriranja sažeti su u objavama na blogu.
Kako menadžer izdanja kreira zakrpe
Koristimo GitLab CI i druge funkcije kao što je naš ChatOps za generiranje zakrpa. Menadžer izdanja započinje izdavanje popravka aktiviranjem ChatOps tima na našem internom kanalu #releases Slack.
/chatops run release prepare 12.10.1ChatOps radi u Slack-u kako bi pokrenuo različite događaje, koje GitLab zatim obrađuje i izvršava. Na primjer, tim za isporuku je postavio ChatOps za automatizaciju raznih stvari za izdavanje zakrpa.
Kada menadžer izdanja pokrene ChatOps tim u Slacku, ostatak posla se automatski dešava u GitLabu koristeći CICD. Postoji dvosmjerna komunikacija između ChatOps-a u Slack-u i GitLab-a tokom procesa izdavanja jer menadžer izdanja aktivira neke od glavnih koraka u procesu.
Video ispod 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 kreiranje zakrpa. Ažuriranje gitlab.com zahteva manje ručnog rada sa stanovišta menadžera izdanja.
Umjesto pokretanja implementacija koristeći ChatOps, koristimo CI funkcije, npr. , s kojim upravitelj izdanja može zakazati određene radnje koje će se izvršiti u potrebno vrijeme. Umjesto ručnog procesa, postoji cjevovod koji se pokreće periodično jednom na sat i koji preuzima nove promjene napravljene u GitLab projektima, pakuje ih i zakazuje implementaciju, te automatski pokreće testiranje, QA i druge potrebne korake.
“Dakle, imamo mnogo implementacija koje se izvršavaju u različitim okruženjima prije gitlab.com, a nakon što su ta okruženja u dobrom stanju i testiranje pokazuje dobre rezultate, upravitelj izdanja pokreće radnje implementacije gitlab.com,” kaže Marin.
CICD tehnologija za podršku ažuriranja gitlab.com automatizuje ceo proces do tačke u kojoj menadžer izdanja mora ručno da pokrene implementaciju proizvodnog okruženja na gitlab.com.
Marin detaljno govori o procesu ažuriranja gitlab.com u videu ispod.
Šta još radi tim za dostavu?
Glavna razlika između gitlab.com procesa ažuriranja i izdavanja zakrpa klijentima u kući je u tome što ovaj drugi proces zahtijeva više vremena i više ručnog rada od menadžera izdanja.
“Ponekad odgađamo objavljivanje zakrpa korisnicima s njihovim instalacijama zbog prijavljenih problema, problema s alatima i zato što postoji mnogo nijansi koje treba uzeti u obzir prilikom objavljivanja jedne zakrpe,” kaže Marin.
Jedan od kratkoročnih ciljeva tima za isporuku je smanjenje količine ručnog rada od strane menadžera izdanja kako bi se ubrzalo izdavanje. Tim radi na pojednostavljivanju, pojednostavljivanju i automatizaciji procesa izdavanja, što će pomoći u rješavanju problema male ozbiljnosti (S3 i S4, cca. prevodilac). Fokusiranje na brzinu je ključni pokazatelj učinka: potrebno je smanjiti MTTP - vrijeme od prijema zahtjeva za spajanje do postavljanja rezultata na gitlab.com - sa trenutnih 50 sati na 8 sati.
Tim za isporuku takođe radi na migraciji gitlab.com na infrastrukturu zasnovanu na Kubernetesu.
Urednička n.b.: Ako ste već čuli za Kubernetes tehnologiju (a ne sumnjam da jeste), ali je još niste dotakli rukama, preporučujem vam učešće na online intenzivnim kursevima , koji će se održati od 28. do 30. septembra, i , koji će se održati od 14. do 16. oktobra. To će vam omogućiti da se pouzdano krećete i radite s tehnologijom.
Ovo su dva pristupa koja teže istom cilju: brza isporuka ažuriranja, kako za gitlab.com tako i za klijente u njihovim objektima.
Ima li ideja ili preporuka za nas?
Svako je dobrodošao da doprinese GitLabu i pozdravljamo povratne informacije naših čitalaca. Ako imate bilo kakvu ideju za naš tim za dostavu, ne oklijevajte uz najavu team: Delivery.
izvor: www.habr.com