„GitLab“ programinės įrangos pataisymus apdorojame dviem būdais: rankiniu būdu ir automatiškai. Skaitykite toliau, kad sužinotumėte apie leidimų tvarkyklės darbą kuriant ir pristatant svarbius naujinimus naudojant automatinį diegimą į gitlab.com, taip pat pataisas, su kuriomis vartotojai gali dirbti savo įrenginiuose.
Rekomenduoju išmaniajame laikrodyje nustatyti priminimą: kiekvieno mėnesio 22 d. naudotojai, dirbantys su „GitLab“ savo patalpose, gali matyti dabartinės mūsų produkto versijos atnaujinimus. Mėnesiniame leidime yra naujų funkcijų, esamų patobulinimų ir dažnai rodomas galutinis bendruomenės prašymų dėl įrankių ar sujungimo rezultatas.
Tačiau, kaip rodo praktika, programinės įrangos kūrimas retai būna be trūkumų. Kai aptinkama klaida arba saugos pažeidžiamumas, pristatymo komandos leidimo tvarkyklė sukuria pataisą mūsų vartotojams su jų diegimu. Gitlab.com atnaujinamas CD proceso metu. Šį CD procesą vadiname automatiniu diegimu, kad išvengtume painiavos su „GitLab“ kompaktinio disko funkcija. Į šį procesą gali būti įtraukti naudotojų, klientų ir mūsų vidinės kūrimo komandos pateiktų ištraukimo užklausų pasiūlymai, kad nuobodžios pataisų išleidimo problemos sprendimas būtų sprendžiamas dviem labai skirtingais būdais.
«Užtikriname, kad viskas, ką kūrėjai sukuria, būtų įdiegta visose aplinkose kiekvieną dieną prieš išleidžiant ją į GitLab.com“, – aiškina , Infrastruktūros skyriaus vyresnysis techninis vadovas. “Pagalvokite apie savo įrenginių leidimus kaip apie gitlab.com diegimo momentines nuotraukas, kurioms pridėjome atskirus veiksmus, kad sukurtume paketą, kad naudotojai galėtų jį naudoti diegdami savo įrenginiuose.".
Nepriklausomai nuo klaidos ar pažeidžiamumo, gitlab.com klientai gaus pataisymus netrukus po jų paskelbimo, o tai yra automatinio kompaktinio disko proceso pranašumas. Pats pataisas vartotojams, turintiems savo diegimą, reikia atskirai paruošti leidimų tvarkyklei.
Pristatymo komanda sunkiai dirba, kad automatizuotų daugumą procesų, susijusių su leidimų kūrimu, siekiant sumažinti (vidutinis laikas iki gamybos, t. y. laikas, praleistas gamybai), laikotarpis nuo kūrėjo sujungimo užklausos apdorojimo iki įdiegimo gitlab.com.
«Pristatymo komandos tikslas yra užtikrinti, kad galėtume greičiau judėti kaip įmonė arba bent jau priversti pristatymo žmones dirbti greičiau, tiesa?, sako Marinas.
Tiek gitlab.com klientai, tiek jų įrenginių naudotojai gauna naudos iš pristatymo komandos pastangų sumažinti ciklo laiką ir pagreitinti diegimą. Šiame straipsnyje paaiškinsime šių dviejų metodų panašumus ir skirtumus. , taip pat apibūdinsime, kaip mūsų pristatymo komanda rengia pataisas naudotojams, dirbantiems savo įrenginiuose, ir kaip užtikriname, kad gitlab.com būtų atnaujinta naudojant automatinį diegimą.
Ką daro išleidimo vadybininkas?
Komandos nariai kas mėnesį mūsų leidimai naudotojams jų patalpose, įskaitant pataisas ir saugos leidimus, kurie gali atsirasti tarp leidimų. Jie taip pat yra atsakingi už vadovavimą įmonės perėjimui prie automatizuoto, nuolatinio diegimo.
Savarankiško diegimo leidimai ir gitlab.com leidimai naudoja panašias darbo eigas, bet veikia skirtingu laiku, aiškina Marin.
Visų pirma, leidimų vadybininkas, neatsižvelgiant į leidimo tipą, užtikrina, kad „GitLab“ būtų prieinama ir saugi nuo pat programos paleidimo gitlab.com svetainėje, taip pat užtikrina, kad tos pačios problemos nepatektų į klientų infrastruktūrą savo pajėgumus.
Kai „GitLab“ pažymima, kad klaida arba pažeidžiamumas yra ištaisytas, leidimo tvarkyklė turi įvertinti, ar ji bus įtraukta į pataisas arba saugos naujinimus, skirtus naudotojams su jų diegimu. Jei jis nusprendžia, kad klaida ar pažeidžiamumas nusipelno atnaujinimo, prasideda parengiamieji darbai.
Išleidimo vadybininkas turi nuspręsti, ar parengti pataisą, ar kada ją įdiegti – ir tai labai priklauso nuo situacijos konteksto.tuo tarpu mašinos ne taip gerai valdo kontekstą kaip žmonės“ – sako Marinas.
Viskas dėl pataisymų
Kas yra pleistrai ir kodėl mums jų reikia?
Išleidimo vadybininkas nusprendžia, ar išleisti pataisą, atsižvelgdamas į klaidos sunkumą.
Klaidos skiriasi priklausomai nuo jų sunkumo. Taigi S4 arba S3 klaidos gali būti stilistinės, pvz., pikselių ar piktogramų poslinkis. Tai ne mažiau svarbu, tačiau jokios reikšmingos įtakos kieno nors darbo eigai neturi, o tai reiškia, kad tikimybė, kad tokioms S3 ar S4 klaidoms bus sukurtas pataisymas, yra maža, aiškina Marin.
Tačiau pažeidžiamumas S1 arba S2 reiškia, kad vartotojas neturėtų atnaujinti į naujausią versiją arba yra rimta klaida, kuri turi įtakos vartotojo darbo eigai. Jei jie yra įtraukti į stebėjimo priemonę, daugelis vartotojų su jais susidūrė, todėl leidimų tvarkyklė nedelsdama pradeda rengti pataisą.
Kai pažeidžiamumų S1 arba S2 pataisa yra paruošta, leidimo tvarkyklė pradeda leisti pataisą.
Pavyzdžiui, „GitLab 12.10.1“ pataisa buvo sukurta po to, kai buvo nustatytos kelios blokavimo problemos ir kūrėjai ištaisė jas sukėlusią problemą. Išleidimo vadybininkas įvertino priskirtų sunkumo lygių teisingumą ir po patvirtinimo buvo pradėtas pataisymo išleidimo procesas, kuris buvo paruoštas per XNUMX valandas po blokavimo problemų aptikimo.
Kai susikaupia daug S4, S3 ir S2, leidimų tvarkyklė žiūri į kontekstą, kad nustatytų pataisos išleidimo skubumą, o kai pasiekiamas tam tikras jų skaičius, jie visi sujungiami ir išleidžiami. Po leidimo pataisymai arba saugos naujinimai apibendrinami tinklaraščio įrašuose.
Kaip leidimų tvarkyklė kuria pataisas
Pataisoms generuoti naudojame „GitLab CI“ ir kitas funkcijas, pvz., „ChatOps“. Leidimų tvarkyklė pradeda pataisos išleidimą suaktyvindama „ChatOps“ komandą mūsų vidiniame kanale #releases Slacke.
/chatops run release prepare 12.10.1„ChatOps“ veikia „Slack“, kad suaktyvintų įvairius įvykius, kuriuos vėliau apdoroja ir vykdo „GitLab“. Pavyzdžiui, pristatymo komanda nustatė „ChatOps“, kad automatizuotų įvairius dalykus ir išleistų pataisas.
Išleidimo tvarkytojui paleidus „ChatOps“ komandą „Slack“, likęs darbas automatiškai atliekamas „GitLab“, naudojant CICD. Išleidimo proceso metu yra dvipusis „ChatOps“ ryšys „Slack“ ir „GitLab“, nes išleidimo tvarkyklė suaktyvina kai kuriuos pagrindinius proceso veiksmus.
Toliau pateiktame vaizdo įraše parodytas techninis „GitLab“ pataisos paruošimo procesas.
Kaip veikia automatinis diegimas gitlab.com
Procesas ir įrankiai, naudojami atnaujinti gitlab.com, yra panašūs į tuos, kurie naudojami kuriant pataisas. Atnaujinant gitlab.com, leidimų tvarkyklės požiūriu reikia mažiau rankinio darbo.
Užuot vykdydami diegimus naudodami ChatOps, naudojame CI funkcijas, pvz. , su kuria leidimų vadybininkas gali suplanuoti tam tikrus veiksmus atlikti reikiamu laiku. Vietoj rankinio proceso yra dujotiekis, kuris periodiškai paleidžiamas kartą per valandą, kuris atsisiunčia naujus GitLab projektų pakeitimus, juos supakuoja ir suplanuoja diegimą bei automatiškai atlieka testavimą, kokybės užtikrinimą ir kitus būtinus veiksmus.
„Taigi, mes turime daug diegimų įvairiose aplinkose prieš gitlab.com, o po to, kai tos aplinkos yra geros būklės ir bandymai rodo gerus rezultatus, leidimo tvarkyklė pradeda gitlab.com diegimo veiksmus“, - sako Marin.
CICD technologija, skirta palaikyti gitlab.com naujinimus, automatizuoja visą procesą iki taško, kai leidimo tvarkyklė turi rankiniu būdu paleisti gamybinės aplinkos diegimą į gitlab.com.
Marin išsamiai aprašo gitlab.com atnaujinimo procesą toliau pateiktame vaizdo įraše.
Ką dar veikia pristatymo komanda?
Pagrindinis skirtumas tarp gitlab.com atnaujinimo procesų ir pataisų išleidimo klientams yra tas, kad pastarasis procesas reikalauja daugiau laiko ir daugiau rankinio darbo iš leidimų tvarkyklės.
„Kartais atidėliojame pataisų išleidimą klientams su jų diegimu dėl praneštų problemų, įrankių problemų ir dėl to, kad yra daug niuansų, į kuriuos reikia atsižvelgti išleidžiant vieną pataisą“, – sako Marin.
Vienas iš trumpalaikių pristatymo komandos tikslų yra sumažinti išleidimo vadybininko rankų darbo apimtį, kad būtų paspartintas išleidimas. Komanda stengiasi supaprastinti, supaprastinti ir automatizuoti išleidimo procesą, kuris padės ištaisyti mažo sunkumo problemas (S3 ir S4, apytiksliai vertėjas). Dėmesys greičiui yra pagrindinis veiklos rodiklis: būtina sumažinti MTTP – laiką nuo sujungimo užklausos gavimo iki rezultato įdiegimo į gitlab.com – nuo dabartinių 50 valandų iki 8 valandų.
Pristatymo komanda taip pat stengiasi perkelti gitlab.com į Kubernetes pagrįstą infrastruktūrą.
Redaktoriaus n.b.: Jei jau girdėjote apie Kubernetes technologiją (ir neabejoju, kad girdėjote), bet dar nepalietėte jos rankomis, rekomenduoju dalyvauti intensyviuose internetiniuose kursuose , kuris vyks rugsėjo 28-30 d., ir , kuris vyks spalio 14–16 d. Tai leis jums užtikrintai naršyti ir dirbti su technologija.
Tai yra du būdai, kuriais siekiama to paties tikslo: greitas naujinimų pristatymas tiek gitlab.com, tiek klientams jų patalpose.
Turite mums idėjų ar rekomendacijų?
Visi kviečiami prisidėti prie „GitLab“ ir laukiame skaitytojų atsiliepimų. Jei turite idėjų mūsų pristatymo komandai, nedvejokite su įspėjimu team: Delivery.
Šaltinis: www.habr.com