V GitLabu obdelujemo popravke programske opreme na dva načina: ročno in samodejno. Nadaljujte z branjem, če želite izvedeti več o nalogi upravitelja izdaje pri ustvarjanju in zagotavljanju pomembnih posodobitev prek samodejnega uvajanja na gitlab.com, kot tudi o popravkih, s katerimi lahko uporabniki delajo na svojih namestitvah.
Priporočam, da na svoji pametni uri nastavite opomnik: vsak 22. dan meseca lahko uporabniki, ki delajo z GitLabom v svojih prostorih, vidijo posodobitve trenutne različice našega izdelka. Mesečna izdaja vsebuje nove funkcije, razvoj obstoječih in pogosto prikazuje končni rezultat zahtev skupnosti za orodja ali združitve.
Toda, kot kaže praksa, je razvoj programske opreme redko brez napak. Ko je odkrit hrošč ali varnostna ranljivost, upravitelj izdaje v skupini za dostavo ustvari popravek za naše uporabnike z njihovimi namestitvami. Gitlab.com se posodobi med postopkom CD-ja. Ta postopek CD-ja imenujemo samodejna uvedba, da bi se izognili zamenjavi s funkcijo CD-ja v GitLabu. Ta postopek lahko vključuje predloge iz zahtevkov za vlečenje, ki so jih poslali uporabniki, stranke in naša interna razvojna ekipa, tako da je reševanje dolgočasnega problema izdajanja popravkov rešeno na dva zelo različna načina.
«Zagotavljamo, da je vse, kar naredijo razvijalci, uvedeno v vsa okolja vsak dan, preden to uvedemo na GitLab.com«, pojasnjuje , višji tehnični vodja, Oddelek za infrastrukturo. "Izdaje za vaše namestitve si predstavljajte kot posnetke za uvedbe na gitlab.com, za katere smo dodali ločene korake za ustvarjanje paketa, tako da ga lahko naši uporabniki uporabijo za namestitev v svoje namestitve.".
Ne glede na napako ali ranljivost bodo stranke gitlab.com prejele popravke kmalu po objavi, kar je prednost avtomatiziranega postopka CD-ja. Popravki za uporabnike z lastnimi namestitvami zahtevajo ločeno pripravo upravitelja izdaje.
Ekipa za dostavo si močno prizadeva avtomatizirati večino procesov, povezanih z ustvarjanjem izdaj za zmanjšanje (srednji čas do proizvodnje, tj. čas, porabljen za proizvodnjo), časovno obdobje od obdelave zahteve za združitev s strani razvijalca do uvedbe na gitlab.com.
«Cilj dostavne ekipe je zagotoviti, da se lahko kot podjetje hitreje premikamo ali vsaj doseči, da dostavljavci delajo hitreje, kajne?, pravi Marin.
Tako stranke gitlab.com kot uporabniki njihovih naprav imajo koristi od prizadevanj dostavne ekipe za skrajšanje časov ciklov in pospešitev uvajanja. V tem članku bomo pojasnili podobnosti in razlike med tema dvema metodama. , opisali pa bomo tudi, kako naša ekipa za dostavo pripravlja popravke za uporabnike, ki se izvajajo na spletnem mestu, in kako posodabljamo gitlab.com s pomočjo samodejnega uvajanja.
Kaj počne upravitelj izdaje?
Člani ekipe mesečno naše izdaje za uporabnike v njihovih prostorih, vključno s popravki in varnostnimi izdajami, ki se lahko pojavijo med izdajami. Odgovorni so tudi za vodenje prehoda podjetja na avtomatizirano, neprekinjeno uvajanje.
Izdaje za samonamestitev in izdaje gitlab.com uporabljajo podobne poteke dela, vendar se izvajajo ob različnih časih, pojasnjuje Marin.
Najprej in predvsem upravitelj izdaje, ne glede na vrsto izdaje, zagotavlja, da je GitLab na voljo in varen od trenutka, ko je aplikacija zagnana na gitlab.com, vključno z zagotavljanjem, da iste težave ne končajo v infrastrukturi strank z njihovimi lastne kapacitete.
Ko je napaka ali ranljivost v GitLabu označena kot odpravljena, mora upravitelj izdaje oceniti, ali bo vključena v popravke ali varnostne posodobitve za uporabnike z njihovimi namestitvami. Če se odloči, da si hrošč ali ranljivost zasluži posodobitev, se začnejo pripravljalna dela.
Upravitelj izdaje se mora odločiti, ali bo pripravil popravek ali kdaj ga bo namestil – in to je zelo odvisno od konteksta situacije, "medtem pa stroji niso tako dobri pri upravljanju konteksta kot ljudje« pravi Marin.
Vse se vrti okoli popravkov
Kaj so popravki in zakaj jih potrebujemo?
Upravitelj izdaje se odloči, ali bo izdal popravek glede na resnost napake.
Napake se razlikujejo glede na njihovo resnost. Napake S4 ali S3 so torej lahko slogovne, na primer premik slikovnih pik ali ikon. To ni nič manj pomembno, vendar nima bistvenega vpliva na potek dela nikogar, kar pomeni, da je verjetnost, da bo ustvarjen popravek za takšne napake S3 ali S4, majhna, pojasnjuje Marin.
Vendar pa ranljivosti S1 ali S2 pomenijo, da uporabnik ne bi smel posodobiti na najnovejšo različico, ali pa obstaja pomembna napaka, ki vpliva na uporabnikov potek dela. Če so vključeni v sledilnik, se je z njimi srečalo veliko uporabnikov, zato upravitelj izdaje takoj začne pripravljati popravek.
Ko je popravek za ranljivosti S1 ali S2 pripravljen, upravitelj izdaje začne izdajati popravek.
Na primer, popravek GitLab 12.10.1 je bil ustvarjen potem, ko je bilo ugotovljenih več težav z blokiranjem in so razvijalci odpravili osnovno težavo, ki jih je povzročala. Upravitelj izdaje je ocenil pravilnost dodeljenih stopenj resnosti in po potrditvi se je sprožil postopek izdaje popravka, ki je bil pripravljen v XNUMX urah po odkritju težav z blokiranjem.
Ko se nabere veliko S4, S3 in S2, upravitelj izdaje pogleda kontekst, da določi nujnost izdaje popravka, in ko je doseženo določeno število teh popravkov, se vsi združijo in izdajo. Popravki po izdaji ali varnostne posodobitve so povzeti v objavah v spletnem dnevniku.
Kako upravitelj izdaje ustvarja popravke
Za ustvarjanje popravkov uporabljamo GitLab CI in druge funkcije, kot je naš ChatOps. Upravitelj izdaje sproži izdajo popravka tako, da aktivira skupino ChatOps na našem internem kanalu #releases v Slacku.
/chatops run release prepare 12.10.1ChatOps deluje znotraj Slacka, da sproži različne dogodke, ki jih nato obdela in izvede GitLab. Dostavna ekipa je na primer nastavila ChatOps za avtomatizacijo različnih stvari za izdajo popravkov.
Ko upravitelj izdaje zažene ekipo ChatOps v Slacku, se ostalo delo samodejno izvede v GitLabu z uporabo CICD. Med postopkom izdaje obstaja dvosmerna komunikacija med ChatOps v Slacku in GitLabu, saj upravitelj izdaje aktivira nekatere glavne korake v procesu.
Spodnji videoposnetek prikazuje tehnični postopek priprave popravka za GitLab.
Kako deluje samodejna uvedba na gitlab.com
Postopek in orodja, ki se uporabljajo za posodobitev gitlab.com, so podobni tistim, ki se uporabljajo za ustvarjanje popravkov. Posodabljanje gitlab.com zahteva manj ročnega dela z vidika upravitelja izdaje.
Namesto izvajanja uvajanj s pomočjo ChatOps uporabljamo funkcije CI, npr. , s katerim lahko upravitelj izdaje načrtuje izvedbo določenih dejanj ob zahtevanem času. Namesto ročnega postopka je na voljo cevovod, ki teče občasno enkrat na uro, ki prenese nove spremembe v projektih GitLab, jih zapakira in razporedi uvajanje ter samodejno izvede testiranje, preverjanje kakovosti in druge potrebne korake.
»Torej imamo veliko uvajanj, ki se izvajajo v različnih okoljih pred gitlab.com, in ko so ta okolja v dobri formi in testiranje pokaže dobre rezultate, upravitelj izdaje začne dejanja uvajanja gitlab.com,« pravi Marin.
Tehnologija CICD za podporo posodobitvam gitlab.com avtomatizira celoten postopek do točke, ko mora upravitelj izdaje ročno zagnati uvajanje produkcijskega okolja na gitlab.com.
Marin gre v podrobnosti o postopku posodabljanja gitlab.com v spodnjem videu.
Kaj še počne ekipa dostave?
Glavna razlika med procesi posodabljanja na gitlab.com in internim objavljanjem popravkov strankam je v tem, da slednji postopek zahteva več časa in več ročnega dela upravitelja izdaje.
»Včasih odložimo objavo popravkov strankam z njihovimi namestitvami zaradi prijavljenih težav, težav z orodji in ker obstaja veliko nians, ki jih je treba upoštevati pri izdaji enega popravka,« pravi Marin.
Eden od kratkoročnih ciljev dostavne ekipe je zmanjšati količino ročnega dela s strani upravitelja izdaje, da bi pospešili izdajo. Ekipa si prizadeva poenostaviti, racionalizirati in avtomatizirati postopek izdaje, kar bo pomagalo doseči popravke za težave nizke resnosti (S3 in S4, pribl. prevajalec). Osredotočenost na hitrost je ključni indikator uspešnosti: potrebno je zmanjšati MTTP – čas od prejema zahteve za združitev do umestitve rezultata na gitlab.com – s trenutnih 50 ur na 8 ur.
Ekipa za dostavo dela tudi na selitvi gitlab.com na infrastrukturo, ki temelji na Kubernetesu.
Opomba urednika: Če ste že slišali za tehnologijo Kubernetes (in ne dvomim, da ste), vendar se je še niste dotaknili z rokami, priporočam udeležbo na spletnih intenzivnih tečajih , ki bo potekal od 28. do 30. septembra, in , ki bo 14.–16. To vam bo omogočilo samozavestno navigacijo in delo s tehnologijo.
To sta dva pristopa, ki zasledujeta isti cilj: hitro dostavo posodobitev, tako za gitlab.com kot za stranke v njihovih obratih.
Kakšne ideje ali priporočila za nas?
Vsakdo je dobrodošel, da prispeva k GitLabu, in veseli smo povratnih informacij naših bralcev. Če imate kakršne koli ideje za našo dostavno ekipo, ne oklevajte z obvestilom team: Delivery.
Vir: www.habr.com