Në GitLab, ne përpunojmë rregullimet e softuerit në dy mënyra: manualisht dhe automatikisht. Lexoni më tej për të mësuar rreth punës së menaxherit të lëshimit për krijimin dhe shpërndarjen e përditësimeve të rëndësishme nëpërmjet vendosjes së automatizuar në gitlab.com, si dhe arna me të cilat përdoruesit të punojnë në instalimet e tyre.
Unë rekomandoj të vendosni një rikujtues në orën tuaj inteligjente: çdo muaj në datën 22, përdoruesit që punojnë me GitLab në objektet e tyre mund të shohin përditësime për versionin aktual të produktit tonë. Publikimi mujor përmban veçori të reja, zhvillime të atyre ekzistuese dhe shpesh tregon rezultatin përfundimtar të kërkesave të komunitetit për vegla pune ose shkrirje.
Por, siç tregon praktika, zhvillimi i softuerit rrallëherë është pa të meta. Kur zbulohet një gabim ose dobësi sigurie, menaxheri i lëshimit në ekipin e dorëzimit krijon një rregullim për përdoruesit tanë me instalimet e tyre. Gitlab.com përditësohet gjatë procesit të CD-së. Ne e quajmë këtë proces CD vendosje automatike për të shmangur konfuzionin me veçorinë e CD-së në GitLab. Ky proces mund të përfshijë sugjerime nga kërkesat tërheqëse të paraqitura nga përdoruesit, klientët dhe ekipi ynë i brendshëm i zhvillimit, në mënyrë që zgjidhja e problemit të mërzitshëm të lëshimit të arnimeve të zgjidhet në dy mënyra shumë të ndryshme.
«Ne sigurojmë që gjithçka që zhvilluesit bëjnë të vendoset në të gjitha mjediset çdo ditë përpara se ta shpërndajë në GitLab.com”, shpjegon , Menaxher i Lartë Teknik, Departamenti i Infrastrukturës. "Mendoni për lëshimet për instalimet tuaja si pamje të çastit për vendosjet e gitlab.com, për të cilat ne kemi shtuar hapa të veçantë për të krijuar një paketë në mënyrë që përdoruesit tanë ta përdorin atë për ta instaluar në instalimet e tyre'.
Pavarësisht nga gabimi ose cenueshmëria, klientët e gitlab.com do të marrin rregullime menjëherë pasi ato të publikohen, gjë që është një përfitim i procesit të automatizuar të CD-së. Arnimet për përdoruesit me instalimet e tyre kërkojnë përgatitje të veçantë nga menaxheri i lëshimit.
Ekipi i dërgesave po punon shumë për të automatizuar shumicën e proceseve të përfshira në krijimin e publikimeve për të reduktuar (koha mesatare deri në prodhim, d.m.th. koha e shpenzuar në prodhim), periudha kohore nga përpunimi i një kërkese për bashkim nga një zhvillues deri në vendosjen në gitlab.com.
«Qëllimi i ekipit të dërgesave është të sigurohet që ne mund të ecim më shpejt si kompani, ose të paktën t'i bëjmë njerëzit e dërgesës të punojnë më shpejt, apo jo?, thotë Marin.
Si klientët e gitlab.com ashtu edhe përdoruesit e instalimeve të tyre përfitojnë nga përpjekjet e ekipit të dorëzimit për të reduktuar kohën e ciklit dhe për të përshpejtuar vendosjet. Në këtë artikull do të shpjegojmë ngjashmëritë dhe ndryshimet midis këtyre dy metodave. , dhe ne do të përshkruajmë gjithashtu se si ekipi ynë i dërgesave përgatit arnime për përdoruesit që punojnë në objektet e tyre, si dhe se si sigurojmë që gitlab.com të jetë i përditësuar duke përdorur vendosjen e automatizuar.
Çfarë bën një menaxher lëshimi?
Anëtarët e ekipit çdo muaj publikimet tona për përdoruesit në objektet e tyre, duke përfshirë arnimet dhe lëshimet e sigurisë që mund të ndodhin ndërmjet publikimeve. Ata janë gjithashtu përgjegjës për udhëheqjen e tranzicionit të kompanisë drejt vendosjes së automatizuar dhe të vazhdueshme.
Publikimet e vetë-instalimit dhe lëshimet e gitlab.com përdorin rrjedha të ngjashme pune, por ekzekutohen në kohë të ndryshme, shpjegon Marin.
Para së gjithash, menaxheri i lëshimit, pavarësisht nga lloji i lëshimit, siguron që GitLab të jetë i disponueshëm dhe i sigurt që nga momenti i lëshimit të aplikacionit në gitlab.com, duke përfshirë sigurimin që të njëjtat çështje të mos përfundojnë në infrastrukturën e klientëve me kapacitetet e veta.
Pasi një gabim ose dobësi të shënohet si i rregulluar në GitLab, menaxheri i lëshimit duhet të vlerësojë se ai do të përfshihet në arnimet ose përditësimet e sigurisë për përdoruesit me instalimet e tyre. Nëse ai vendos që një gabim ose dobësi meriton një përditësim, fillon puna përgatitore.
Menaxheri i lëshimit duhet të vendosë nëse do të përgatisë një rregullim, ose kur do ta vendosë atë - dhe kjo varet shumë nga konteksti i situatës, "Ndërkohë, makinat nuk janë aq të mira në menaxhimin e kontekstit sa njerëzit“, thotë Marin.
Gjithçka ka të bëjë me rregullimet
Çfarë janë arna dhe pse na duhen ato?
Menaxheri i lëshimit vendos nëse do të lëshojë një rregullim bazuar në ashpërsinë e defektit.
Gabimet ndryshojnë në varësi të ashpërsisë së tyre. Pra, gabimet S4 ose S3 mund të jenë stilistike, të tilla si zhvendosja e pikselit ose ikonës. Kjo nuk është më pak e rëndësishme, por nuk ka asnjë ndikim të rëndësishëm në rrjedhën e punës së askujt, që do të thotë se gjasat që të krijohen një rregullim për gabime të tilla S3 ose S4 janë të vogla, shpjegon Marin.
Megjithatë, dobësitë S1 ose S2 nënkuptojnë që përdoruesi nuk duhet të përditësojë në versionin më të fundit, ose ka një gabim të rëndësishëm që ndikon në rrjedhën e punës së përdoruesit. Nëse ato përfshihen në gjurmues, shumë përdorues i kanë hasur, kështu që menaxheri i lëshimit fillon menjëherë të përgatisë një rregullim.
Pasi një patch për dobësitë S1 ose S2 është gati, menaxheri i lëshimit fillon të lëshojë patch-in.
Për shembull, patch-i GitLab 12.10.1 u krijua pasi u identifikuan disa probleme bllokimi dhe zhvilluesit rregulluan problemin themelor që po i shkaktonte ato. Menaxheri i lëshimit vlerësoi korrektësinë e niveleve të përcaktuara të ashpërsisë dhe pas konfirmimit, filloi procesi i nxjerrjes së një rregullimi, i cili ishte gati brenda XNUMX orëve pasi u zbuluan problemet e bllokimit.
Kur grumbullohen shumë S4, S3 dhe S2, menaxheri i lëshimit shikon kontekstin për të përcaktuar urgjencën e lëshimit të një rregullimi dhe kur arrihet një numër i caktuar i tyre, të gjitha kombinohen dhe lëshohen. Rregullimet pas publikimit ose përditësimet e sigurisë përmblidhen në postimet e blogut.
Si krijon arna një menaxher lëshimi
Ne përdorim GitLab CI dhe veçori të tjera si ChatOps për të gjeneruar arna. Menaxheri i lëshimit fillon lëshimin e rregullimit duke aktivizuar ekipin ChatOps në kanalin tonë të brendshëm #releases në Slack.
/chatops run release prepare 12.10.1ChatOps funksionon brenda Slack për të shkaktuar ngjarje të ndryshme, të cilat më pas përpunohen dhe ekzekutohen nga GitLab. Për shembull, ekipi i dërgesave krijoi ChatOps për të automatizuar gjëra të ndryshme për të lëshuar arna.
Pasi menaxheri i lëshimit të nisë ekipin ChatOps në Slack, pjesa tjetër e punës ndodh automatikisht në GitLab duke përdorur CICD. Ekziston një komunikim i dyanshëm midis ChatOps në Slack dhe GitLab gjatë procesit të lëshimit pasi menaxheri i lëshimit aktivizon disa nga hapat kryesorë në proces.
Videoja më poshtë tregon procesin teknik të përgatitjes së një patch për GitLab.
Si funksionon vendosja automatike në gitlab.com
Procesi dhe mjetet e përdorura për përditësimin e gitlab.com janë të ngjashme me ato të përdorura për të krijuar arna. Përditësimi i gitlab.com kërkon më pak punë manuale nga këndvështrimi i menaxherit të lëshimit.
Në vend që të ekzekutojmë vendosjet duke përdorur ChatOps, ne përdorim veçoritë CI p.sh. , me të cilin menaxheri i lëshimit mund të planifikojë veprime të caktuara që do të kryhen në kohën e kërkuar. Në vend të një procesi manual, ekziston një tubacion që funksionon periodikisht një herë në orë që shkarkon ndryshimet e reja të bëra në projektet e GitLab, i paketon ato dhe planifikon vendosjen dhe ekzekuton automatikisht testimin, QA dhe hapat e tjerë të nevojshëm.
"Pra, ne kemi shumë vendosje që ekzekutohen në mjedise të ndryshme përpara gitlab.com, dhe pasi ato mjedise janë në gjendje të mirë dhe testimi tregon rezultate të mira, menaxheri i lëshimit fillon veprimet e vendosjes së gitlab.com," thotë Marin.
Teknologjia CICD për mbështetjen e përditësimeve të gitlab.com automatizon të gjithë procesin deri në pikën ku menaxheri i lëshimit duhet të nisë manualisht vendosjen e mjedisit të prodhimit te gitlab.com.
Marin hyn në detaje rreth procesit të përditësimit të gitlab.com në videon më poshtë.
Çfarë tjetër bën ekipi i dorëzimit?
Dallimi kryesor midis proceseve të përditësimit të gitlab.com dhe lëshimit të arnimeve për klientët brenda shtëpisë është se procesi i fundit kërkon më shumë kohë dhe më shumë punë manuale nga menaxheri i lëshimit.
"Ne ndonjëherë vonojmë lëshimin e arnimeve për klientët me instalimet e tyre për shkak të problemeve të raportuara, çështjeve të veglave dhe për shkak se ka shumë nuanca që duhen marrë parasysh kur lëshojmë një copë toke të vetme," thotë Marin.
Një nga qëllimet afatshkurtra të ekipit të dorëzimit është të zvogëlojë sasinë e punës manuale nga ana e menaxherit të lëshimit për të përshpejtuar lëshimin. Ekipi po punon për të thjeshtuar, thjeshtuar dhe automatizuar procesin e lëshimit, i cili do të ndihmojë në marrjen e rregullimeve për çështjet me ashpërsi të ulët (S3 dhe S4, përafërsisht. përkthyes). Përqendrimi në shpejtësi është një tregues kyç i performancës: është e nevojshme të reduktohet MTTP - koha nga marrja e një kërkese për bashkim deri në vendosjen e rezultatit në gitlab.com - nga 50 orë aktuale në 8 orë.
Ekipi i dërgesave po punon gjithashtu në migrimin e gitlab.com në një infrastrukturë të bazuar në Kubernetes.
Nr.b e redaktorit.: Nëse keni dëgjuar tashmë për teknologjinë Kubernetes (dhe nuk kam dyshim se keni), por nuk e keni prekur ende me duar, ju rekomandoj të merrni pjesë në kurse intensive në internet , e cila do të mbahet 28-30 shtator, dhe , e cila do të zhvillohet në datat 14-16 tetor. Kjo do t'ju lejojë të lundroni me besim dhe të punoni me teknologjinë.
Këto janë dy qasje që ndjekin të njëjtin qëllim: dërgim i shpejtë i përditësimeve, si për gitlab.com ashtu edhe për klientët në objektet e tyre.
Ndonjë ide apo rekomandim për ne?
Të gjithë janë të mirëpritur të kontribuojnë në GitLab dhe ne mirëpresim reagimet nga lexuesit tanë. Nëse keni ndonjë ide për ekipin tonë të dërgesave, mos hezitoni me njoftim team: Delivery.
Burimi: www.habr.com