Kuidas me GitLabis tarkvarapaigad välja anname

GitLabis töötleme tarkvaraparandusi kahel viisil: käsitsi ja automaatselt. Lugege edasi, et saada teavet väljalaskehalduri töö kohta oluliste värskenduste loomisel ja edastamisel saidile gitlab.com automaatse juurutamise kaudu, samuti paikade kohta, millega kasutajad saavad oma installides töötada.

Soovitan seadistada nutikellale meeldetuletus: iga kuu 22. kuupäeval näevad GitLabiga töötavad kasutajad meie toote praeguse versiooni värskendusi. Igakuine väljalase sisaldab uusi funktsioone, olemasolevate arendusi ja sageli kuvatakse kogukonna tööriistade või liitmiste taotluste lõpptulemus.

Kuid nagu praktika näitab, on tarkvaraarendus harva vigadeta. Kui avastatakse viga või turvaauku, loob tarnemeeskonna väljalaskehaldur meie kasutajatele nende installidega paiga. Gitlab.com-i värskendatakse CD-protsessi ajal. Nimetame seda CD-protsessi automaatseks juurutamiseks, et vältida segadust GitLabi CD-funktsiooniga. See protsess võib hõlmata kasutajate, klientide ja meie sisemise arendusmeeskonna esitatud tõmbetaotluste soovitusi, nii et igav plaastrite vabastamise probleem lahendatakse kahel väga erineval viisil.

«Tagame, et kõike, mida arendajad loovad, juurutatakse iga päev kõikides keskkondades enne selle GitLab.com-i avaldamist", selgitab Marin Jankovki, infrastruktuuriosakonna vanemtehniline juht. "Mõelge oma installide väljalasetele kui gitlab.com-i juurutuste hetktõmmistele, mille jaoks oleme lisanud paketi loomiseks eraldi sammud, et meie kasutajad saaksid seda kasutada oma installidesse installimiseks'.

Olenemata veast või haavatavusest saavad gitlab.com-i kliendid parandused varsti pärast nende avaldamist, mis on automaatse CD-protsessi eelis. Oma installitud kasutajate paigad nõuavad väljalaskehalduri eraldi ettevalmistamist.

Edastusmeeskond teeb kõvasti tööd, et automatiseerida enamikku väljalaske loomise protsessidest, mida vähendada MTTP (keskmine aeg tootmiseni, st tootmisele kulutatud aeg), ajavahemik alates ühendamistaotluse töötlemisest arendaja poolt kuni juurutamiseni saidil gitlab.com.

«Tarnemeeskonna eesmärk on tagada, et saaksime ettevõttena kiiremini edasi liikuda või vähemalt tarnijad kiiremini tööle panna, eks?, ütleb Marin.

Nii gitlab.com-i kliendid kui ka nende installide kasutajad saavad kasu tarnemeeskonna pingutustest tsükliaegade vähendamisel ja juurutamise kiirendamisel. Selles artiklis selgitame nende kahe meetodi sarnasusi ja erinevusi. küsimustes, ning kirjeldame ka seda, kuidas meie kohaletoimetamismeeskond valmistab ette paigad nende rajatistes töötavatele kasutajatele ning kuidas tagame, et gitlab.com on automatiseeritud juurutuse abil ajakohane.

Mida väljalaskehaldur teeb?

Meeskonnaliikmed igakuiselt väljalaskejuhi rolli üle andma meie väljalasked kasutajatele nende rajatistes, sealhulgas paigad ja turbeväljaanded, mis võivad väljalaske vahel esineda. Nad vastutavad ka ettevõtte automatiseeritud pidevale kasutuselevõtule ülemineku juhtimise eest.

Marin selgitab, et iseinstallivad versioonid ja gitlab.com-i versioonid kasutavad sarnaseid töövooge, kuid töötavad erinevatel aegadel.

Eelkõige tagab väljalaskehaldur, olenemata väljalaske tüübist, selle, et GitLab on saadaval ja turvaline alates rakenduse käivitamisest saidil gitlab.com, sealhulgas tagab, et samad probleemid ei satuks nende klientide infrastruktuuri. enda võimsused.

Kui viga või haavatavus on GitLabis parandatuks märgitud, peab väljalaskehaldur hindama, kas see kaasatakse kasutajate installimiste paikadesse või turvavärskendustesse. Kui ta otsustab, et viga või haavatavus väärib värskendamist, algab ettevalmistustöö.

Väljalaskehaldur peab otsustama, kas valmistada ette parandus või millal see juurutada – ja see sõltub suuresti olukorra kontekstist,vahepeal ei oska masinad nii hästi konteksti juhtida kui inimesed"ütleb Marin.

See kõik puudutab parandusi

Mis on plaastrid ja miks me neid vajame?

Väljalaskehaldur otsustab vea tõsiduse põhjal, kas väljastada paranduse.

Vead sõltuvad nende tõsidusest. Seega võivad S4 või S3 vead olla stilistilised, näiteks pikslite või ikoonide nihkumine. See pole vähem oluline, kuid see ei mõjuta oluliselt kellegi töövoogu, mis tähendab, et tõenäosus, et sellistele S3 või S4 vigadele parandus luuakse, on väike, selgitab Marin.

Turvaaugud S1 või S2 tähendavad aga seda, et kasutaja ei tohiks uusimale versioonile värskendada või on märkimisväärne viga, mis mõjutab kasutaja töövoogu. Kui need on jälgijasse kaasatud, on paljud kasutajad nendega kokku puutunud, nii et väljalaskehaldur alustab kohe paranduse ettevalmistamist.

Kui haavatavuste S1 või S2 plaaster on valmis, alustab väljalaskehaldur plaastri vabastamist.

Näiteks GitLabi 12.10.1 plaaster loodi pärast seda, kui tuvastati mitu blokeerimisprobleemi ja arendajad lahendasid neid põhjustanud probleemi. Väljalaskehaldur hindas määratud raskusastmete õigsust ja pärast kinnitamist käivitati paranduse vabastamise protsess, mis oli valmis XNUMX tunni jooksul pärast blokeerimisprobleemide avastamist.

Kui koguneb palju S4, S3 ja S2, vaatab väljalaskehaldur konteksti, et teha kindlaks paranduse avaldamise kiireloomulisus, ning kui teatud arv neist on saavutatud, ühendatakse need kõik kokku ja vabastatakse. Väljalaskejärgsed parandused või turvavärskendused on kokku võetud ajaveebi postitustes.

Kuidas väljalaskehaldur plaastreid loob

Kasutame plaastrite loomiseks GitLab CI-d ja muid funktsioone, nagu meie ChatOps. Väljalaskehaldur alustab paranduse väljaandmist, aktiveerides meie sisekanalil ChatOpsi meeskonna #releases Slackis.

/chatops run release prepare 12.10.1

ChatOps töötab Slackis erinevate sündmuste käivitamiseks, mida GitLab seejärel töötleb ja käivitab. Näiteks seadistas kohaletoimetamise meeskond ChatOpsi, et automatiseerida mitmesuguseid asju plaastrite vabastamiseks.

Kui väljalaskehaldur käivitab ChatOpsi meeskonna Slackis, toimub ülejäänud töö automaatselt GitLabis, kasutades CICD-d. Väljalaskeprotsessi ajal on Slacki ChatOpsi ja GitLabi vahel kahesuunaline suhtlus, kuna väljalaskehaldur aktiveerib protsessi mõned peamised etapid.

Allolev video näitab GitLabi plaastri ettevalmistamise tehnilist protsessi.

Kuidas automaatne juurutamine veebisaidil gitlab.com töötab

Gitlab.com-i värskendamiseks kasutatud protsess ja tööriistad on sarnased paikade loomisel kasutatavatega. Gitlab.com-i värskendamine nõuab väljalaskehalduri seisukohast vähem käsitsitööd.

Selle asemel, et käivitada juurutusi ChatOpsi abil, kasutame CI funktsioone nt. planeeritud torujuhtmed, millega väljalaskehaldur saab ajastada teatud toiminguid vajalikul ajal sooritamiseks. Manuaalse protsessi asemel on perioodiliselt kord tunnis jooksev konveier, mis laadib alla GitLabi projektidesse tehtud uued muudatused, pakib need ja ajastab juurutamise ning käivitab automaatselt testimise, kvaliteedikontrolli ja muud vajalikud sammud.

"Nii et meil on enne gitlab.com-i erinevates keskkondades palju juurutusi ja pärast seda, kui need keskkonnad on heas korras ja testimine näitab häid tulemusi, alustab väljalaskehaldur gitlab.com-i juurutustoiminguid," ütleb Marin.

CICD-tehnoloogia gitlab.com-i värskenduste toetamiseks automatiseerib kogu protsessi kuni punktini, kus väljalaskehaldur peab käsitsi käivitama tootmiskeskkonna juurutamise saidile gitlab.com.

Marin räägib allolevas videos üksikasjalikult gitlab.com-i värskendusprotsessist.

Mida tarnemeeskond veel teeb?

Peamine erinevus gitlab.com-i värskendusprotsesside ja klientidele ettevõttesiseselt plaastrite väljastamise vahel seisneb selles, et viimane protsess nõuab väljalaskehaldurilt rohkem aega ja käsitsitööd.

"Mõnikord lükkame plaastrite väljastamist klientidele koos nende installidega edasi teatatud probleemide ja tööriistaprobleemide tõttu ning seetõttu, et ühe plaastri väljastamisel tuleb arvestada paljude nüanssidega," ütleb Marin.

Üks tarnemeeskonna lühiajalisi eesmärke on vabastamise kiirendamiseks vähendada väljalaskehalduri käsitsitööd. Meeskond töötab väljalaskeprotsessi lihtsustamise, sujuvamaks muutmise ja automatiseerimise nimel, mis aitab leida lahendusi madala raskusastmega probleemidele (S3 ja S4, u. tõlkija). Kiirusele keskendumine on peamine jõudlusnäitaja: on vaja vähendada MTTP-d - aega, mis kulub liitmistaotluse saamisest kuni tulemuse juurutamiseni saidile gitlab.com - praeguselt 50 tunnilt 8 tunnile.

Tarnemeeskond tegeleb ka saidi gitlab.com migreerimisega Kubernetese-põhisele infrastruktuurile.

Toimetaja nr.: Kui olete Kubernetese tehnoloogiast juba kuulnud (ja ma ei kahtle, et olete), kuid pole seda veel käega puudutanud, soovitan osaleda veebipõhistel intensiivkursustel Kubernetese baas, mis toimub 28-30 september ja Kubernetes Mega, mis toimub 14.–16. See võimaldab teil enesekindlalt navigeerida ja tehnoloogiaga töötada.

Need on kaks lähenemisviisi, millel on sama eesmärk: värskenduste kiire kohaletoimetamine nii saidile gitlab.com kui ka klientidele nende rajatistes.

Kas teil on meile ideid või soovitusi?

Kõik on teretulnud GitLabi panustama ja ootame oma lugejate tagasisidet. Kui teil on ideid meie kohaletoimetamismeeskonna jaoks, ärge kõhelge luua rakendus teatega team: Delivery.

Allikas: www.habr.com