Hjá GitLab vinnum við hugbúnaðarleiðréttingar á tvo vegu: handvirkt og sjálfvirkt. Lestu áfram til að læra um starf útgáfustjórans við að búa til og afhenda mikilvægar uppfærslur með sjálfvirkri dreifingu á gitlab.com, sem og plástra fyrir notendur til að vinna með á eigin uppsetningu.
Ég mæli með að setja áminningu á snjallúrið þitt: í hverjum mánuði þann 22. geta notendur sem vinna með GitLab á aðstöðu þeirra séð uppfærslur á núverandi útgáfu af vörunni okkar. Mánaðarlega útgáfan inniheldur nýja eiginleika, þróun þeirra sem fyrir eru og sýnir oft lokaniðurstöðuna af beiðnum samfélagsins um verkfæri eða sameiningu.
En eins og æfingin sýnir er hugbúnaðarþróun sjaldan gallalaus. Þegar galli eða öryggisveikleiki uppgötvast, býr útgáfustjórinn í afhendingarteyminu til plástur fyrir notendur okkar með uppsetningum þeirra. Gitlab.com er uppfært meðan á geisladisknum stendur. Við köllum þetta geisladiskaferli sjálfvirka dreifingu til að forðast rugling við geisladiskaeiginleikann í GitLab. Þetta ferli getur falið í sér tillögur úr beiðnum um aðdráttarafl sem notendur, viðskiptavinir og innra þróunarteymi okkar hafa lagt fram, þannig að lausn á leiðinlegu vandamálinu við að gefa út plástra er leyst á tvo mjög mismunandi vegu.
«Við tryggjum að allt sem forritarar búa til sé sent í öll umhverfi á hverjum degi áður en það er sett út á GitLab.com“, útskýrir , yfirtæknistjóri, innviðadeild. "Hugsaðu um útgáfur fyrir uppsetningar þínar sem skyndimyndir fyrir uppsetningar á gitlab.com, sem við höfum bætt við sérstökum skrefum til að búa til pakka svo að notendur okkar geti notað hann til að setja upp á uppsetningarnar sínar'.
Burtséð frá villunni eða varnarleysi, munu viðskiptavinir gitlab.com fá lagfæringar stuttu eftir að þær eru birtar, sem er ávinningur af sjálfvirku geisladiskferlinu. Plástrar fyrir notendur með eigin uppsetningar þurfa sérstakan undirbúning af útgáfustjóra.
Afhendingarteymið vinnur hörðum höndum að því að gera sjálfvirkan flesta ferla sem taka þátt í að búa til útgáfur til að draga úr (meðaltími fram að framleiðslu, þ.e. tími sem fer í framleiðslu), tíminn frá því að vinna úr sameiningarbeiðni frá þróunaraðila til uppsetningar á gitlab.com.
«Markmið afgreiðsluteymis er að tryggja að við getum hreyft okkur hraðar sem fyrirtæki, eða að minnsta kosti látið afgreiðslufólkið vinna hraðar, ekki satt?, segir Marin.
Bæði viðskiptavinir gitlab.com og notendur uppsetninga þeirra njóta góðs af viðleitni afhendingarteymis til að stytta lotutíma og flýta fyrir uppsetningu. Í þessari grein munum við útskýra líkindi og mun á þessum tveimur aðferðum. , og við munum einnig lýsa því hvernig afhendingarteymi okkar undirbýr plástra fyrir notendur sem keyra á staðnum og hvernig við höldum gitlab.com uppfærðum með sjálfvirkri uppsetningu.
Hvað gerir útgáfustjóri?
Liðsmenn mánaðarlega útgáfur okkar til notenda á aðstöðu þeirra, þar á meðal plástra og öryggisútgáfur sem kunna að eiga sér stað á milli útgáfur. Þeir eru einnig ábyrgir fyrir því að leiða umskipti fyrirtækisins yfir í sjálfvirka, stöðuga uppsetningu.
Sjálfuppsetningarútgáfur og gitlab.com útgáfur nota svipað verkflæði en keyra á mismunandi tímum, útskýrir Marin.
Fyrst og fremst tryggir útgáfustjórinn, óháð útgáfu útgáfunnar, að GitLab sé tiltækt og öruggt frá því augnabliki sem forritið er opnað á gitlab.com, þar á meðal að tryggja að sömu vandamál lendi ekki í innviðum viðskiptavina með þeirra eigin getu.
Þegar villa eða varnarleysi hefur verið merkt sem lagfærð í GitLab verður útgáfustjórinn að meta að það verði innifalið í plástrum eða öryggisuppfærslum fyrir notendur með uppsetningu þeirra. Ef hann ákveður að galli eða veikleiki verðskuldi uppfærslu hefst undirbúningsvinnan.
Útgáfustjórinn verður að ákveða hvort á að undirbúa lagfæringu eða hvenær á að dreifa henni - og þetta er mjög háð samhengi ástandsins, "í millitíðinni eru vélar ekki eins góðar í að stjórna samhengi og fólk“ segir Marin.
Þetta snýst allt um lagfæringar
Hvað eru plástrar og hvers vegna þurfum við þá?
Útgáfustjóri ákveður hvort losa eigi lagfæringu út frá alvarleika villunnar.
Villur eru mismunandi eftir alvarleika þeirra. Svo S4 eða S3 villur geta verið stílfræðilegar, eins og pixla eða tilfærslu tákna. Þetta er ekki síður mikilvægt, en það hefur engin marktæk áhrif á vinnuflæði neins, sem þýðir að líkurnar á að lagfæring verði búin til fyrir slíkar S3 eða S4 villur eru litlar, útskýrir Marin.
Hins vegar, veikleikar S1 eða S2 þýða að notandinn ætti ekki að uppfæra í nýjustu útgáfuna, eða það er veruleg villa sem hefur áhrif á vinnuflæði notandans. Ef þeir eru innifaldir í rekja sporinu hafa margir notendur rekist á þá, svo útgáfustjórinn byrjar strax að undirbúa lagfæringu.
Þegar plástur fyrir varnarleysi S1 eða S2 er tilbúinn byrjar útgáfustjóri að gefa út plásturinn.
Til dæmis var GitLab 12.10.1 plásturinn búinn til eftir að nokkur hindrunarvandamál voru auðkennd og verktaki lagaði undirliggjandi vandamál sem olli þeim. Útgáfustjórinn mat á réttmæti úthlutaðra alvarleikastiga og eftir staðfestingu var ræst ferli við að losa lagfæringu sem var tilbúið innan XNUMX klukkustunda eftir að hindrunarvandamálin komu í ljós.
Þegar mikið af S4, S3 og S2 safnast upp, skoðar útgáfustjóri samhengið til að ákvarða hversu brýnt er að gefa út lagfæringu og þegar ákveðinn fjöldi þeirra er náð eru þær allar sameinaðar og gefnar út. Lagfæringar eða öryggisuppfærslur eftir útgáfu eru teknar saman í bloggfærslum.
Hvernig útgáfustjóri býr til plástra
Við notum GitLab CI og aðra eiginleika eins og ChatOps okkar til að búa til plástra. Útgáfustjóri byrjar útgáfu lagfæringarinnar með því að virkja ChatOps teymið á innri rásinni okkar #releases í Slack.
/chatops run release prepare 12.10.1ChatOps vinnur innan Slack til að koma af stað mismunandi atburðum, sem síðan eru unnar og keyrðir af GitLab. Til dæmis setti afhendingarteymið upp ChatOps til að gera ýmislegt sjálfvirkt til að gefa út plástra.
Þegar útgáfustjórinn byrjar ChatOps teymið í Slack gerist restin af vinnu sjálfkrafa í GitLab með CICD. Það eru tvíhliða samskipti á milli ChatOps í Slack og GitLab meðan á útgáfuferlinu stendur þar sem útgáfustjóri virkjar nokkur af helstu skrefum ferlisins.
Myndbandið hér að neðan sýnir tæknilega ferlið við að útbúa plástur fyrir GitLab.
Hvernig sjálfvirk uppsetning virkar á gitlab.com
Ferlið og verkfærin sem notuð eru til að uppfæra gitlab.com eru svipuð þeim sem notuð eru til að búa til plástra. Uppfærsla gitlab.com krefst minni handavinnu frá sjónarhóli útgáfustjórans.
Í stað þess að keyra dreifingar með ChatOps notum við CI eiginleika t.d. , sem útgáfustjóri getur skipulagt ákveðnar aðgerðir til að framkvæma á tilskildum tíma. Í stað handvirks ferlis er leiðsla sem keyrir reglulega einu sinni á klukkustund sem hleður niður nýju breytingunum sem gerðar eru á GitLab verkefnum, pakkar þeim og áætlar uppsetningu og keyrir sjálfkrafa prófanir, QA og önnur nauðsynleg skref.
„Þannig að við erum með fullt af dreifingum í gangi í mismunandi umhverfi fyrir gitlab.com, og eftir að þessi umhverfi eru í góðu formi og prófanir sýna góðan árangur byrjar útgáfustjórinn á gitlab.com dreifingaraðgerðunum,“ segir Marin.
CICD tækni til að styðja gitlab.com uppfærslur gerir allt ferlið sjálfvirkt að þeim stað þar sem útgáfustjóri verður að ræsa dreifingu framleiðsluumhverfisins handvirkt á gitlab.com.
Marin fer í smáatriðum um uppfærsluferlið gitlab.com í myndbandinu hér að neðan.
Hvað gerir afgreiðsluteymið annað?
Helsti munurinn á gitlab.com uppfærsluferlunum og því að gefa út plástra til viðskiptavina innanhúss er að síðara ferlið krefst meiri tíma og meiri handvirkrar vinnu frá útgáfustjóranum.
„Við frestum stundum að gefa út plástra til viðskiptavina með uppsetningar þeirra vegna tilkynntra vandamála, verkfæravandamála og vegna þess að það eru mörg blæbrigði sem þarf að taka tillit til þegar einn plástur er gefinn út,“ segir Marin.
Eitt af skammtímamarkmiðum afgreiðsluteymis er að draga úr handavinnu af hálfu útgáfustjóra til að flýta fyrir útgáfunni. Teymið vinnur að því að einfalda, hagræða og gera útgáfuferlið sjálfvirkt, sem mun hjálpa til við að lagfæra vandamál sem eru lítil alvar (S3 og S4, ca. þýðandi). Að einblína á hraða er lykilframmistöðuvísir: það er nauðsynlegt að draga úr MTTP - tímanum frá móttöku sameiningarbeiðni þar til niðurstaðan er send á gitlab.com - úr núverandi 50 klukkustundum í 8 klukkustundir.
Afhendingarteymið vinnur einnig að því að flytja gitlab.com yfir í Kubernetes innviði.
Athugið ritstjóra: Ef þú hefur þegar heyrt um Kubernetes tækni (og ég efast ekki um að þú hafir það), en hefur ekki snert hana með höndum þínum, mæli ég með því að taka þátt í netnámskeiðum , sem haldinn verður 28. – 30. september, og , sem fer fram 14.–16. október. Þetta gerir þér kleift að vafra um og vinna með tæknina.
Þetta eru tvær aðferðir sem sækjast eftir sama markmiði: fljótur afhendingu uppfærslur, bæði fyrir gitlab.com og fyrir viðskiptavini á aðstöðu þeirra.
Einhverjar hugmyndir eða ráðleggingar fyrir okkur?
Öllum er velkomið að leggja sitt af mörkum til GitLab og við fögnum viðbrögðum frá lesendum okkar. Ef þú hefur einhverjar hugmyndir fyrir afhendingarteymi okkar skaltu ekki hika við með fyrirvara team: Delivery.
Heimild: www.habr.com