By GitLab verwerk ons sagteware-oplossings op twee maniere: handmatig en outomaties. Lees verder om meer te wete te kom oor die vrystellingbestuurder se taak om belangrike opdaterings te skep en te lewer via outomatiese ontplooiing na gitlab.com, sowel as pleisters vir gebruikers om mee te werk op hul eie installasies.
Ek beveel aan om 'n herinnering op jou slimhorlosie te stel: elke maand op die 22ste kan gebruikers wat met GitLab by hul fasiliteite werk, opdaterings aan die huidige weergawe van ons produk sien. Die maandelikse vrystelling bevat nuwe kenmerke, ontwikkelings van bestaandes, en wys dikwels die eindresultaat van gemeenskapsversoeke vir gereedskap of samesmeltings.
Maar, soos die praktyk toon, is sagteware-ontwikkeling selde sonder foute. Wanneer 'n fout of sekuriteitkwesbaarheid ontdek word, skep die vrystellingbestuurder in die afleweringspan 'n pleister vir ons gebruikers met hul installasies. Gitlab.com word opgedateer tydens die CD-proses. Ons noem hierdie CD-proses outomatiese ontplooiing om verwarring met die CD-funksie in GitLab te voorkom. Hierdie proses kan voorstelle insluit van trekversoeke wat deur gebruikers, kliënte en ons interne ontwikkelingspan ingedien is, sodat die oplossing van die vervelige probleem van die vrystelling van pleisters op twee baie verskillende maniere opgelos word.
«Ons verseker dat alles wat ontwikkelaars maak, elke dag na alle omgewings ontplooi word voordat dit na GitLab.com uitgerol word.", verduidelik , Senior Tegniese Bestuurder, Infrastruktuurafdeling. "Dink aan vrystellings vir jou installasies as momentopnames vir gitlab.com-ontplooiings, waarvoor ons aparte stappe bygevoeg het om 'n pakket te skep sodat ons gebruikers dit kan gebruik om op hul installasies te installeer".
Ongeag die fout of kwesbaarheid, sal gitlab.com-kliënte regstellings ontvang kort nadat dit gepubliseer is, wat 'n voordeel van die outomatiese CD-proses is. Patches vir gebruikers met hul eie installasies vereis aparte voorbereiding deur die vrystellingbestuurder.
Die afleweringspan werk hard om die meeste van die prosesse wat betrokke is by die skep van vrystellings te outomatiseer om te verminder (gemiddelde tyd tot produksie, dit wil sê tyd wat aan produksie bestee word), die tydperk vanaf die verwerking van 'n samesmeltingsversoek deur 'n ontwikkelaar tot ontplooiing op gitlab.com.
«Die doel van die afleweringspan is om seker te maak dat ons as 'n maatskappy vinniger kan beweeg, of ten minste die afleweringsmense vinniger kan laat werk, reg?, sê Marin.
Beide gitlab.com-kliënte en gebruikers van hul installasies trek voordeel uit die afleweringspan se pogings om siklustye te verminder en implementering te bespoedig. In hierdie artikel sal ons die ooreenkomste en verskille tussen hierdie twee metodes verduidelik. , en ons sal ook beskryf hoe ons afleweringspan pleisters voorberei vir gebruikers wat aan hul fasiliteite werk, asook hoe ons verseker dat gitlab.com op datum is met behulp van outomatiese ontplooiing.
Wat doen 'n vrystellingbestuurder?
Spanlede maandeliks ons vrystellings aan gebruikers by hul fasiliteite, insluitend regstellings en sekuriteitvrystellings wat tussen vrystellings kan voorkom. Hulle is ook verantwoordelik om die maatskappy se oorgang na outomatiese, deurlopende ontplooiing te lei.
Selfinstallasievrystellings en gitlab.com-vrystellings gebruik soortgelyke werkvloeie, maar loop op verskillende tye, verduidelik Marin.
In die eerste plek verseker die vrystellingbestuurder, ongeag die tipe vrystelling, dat GitLab beskikbaar en veilig is vanaf die oomblik dat die toepassing op gitlab.com bekendgestel word, insluitend om te verseker dat dieselfde probleme nie in die infrastruktuur van kliënte beland met hul eie vermoëns.
Sodra 'n fout of kwesbaarheid in GitLab as reggestel gemerk is, moet die vrystellingbestuurder evalueer dat dit ingesluit sal word by die pleisters of sekuriteitsopdaterings vir gebruikers met hul installasies. As hy besluit dat 'n fout of kwesbaarheid 'n opdatering verdien, begin die voorbereidende werk.
Die vrystellingbestuurder moet besluit of om 'n oplossing voor te berei, of wanneer om dit te ontplooi - en dit is hoogs afhanklik van die konteks van die situasie, "intussen is masjiene nie so goed in die bestuur van konteks soos mense nie" sê Marin.
Dit gaan alles oor die regstellings
Wat is pleisters en hoekom het ons dit nodig?
Die vrystellingbestuurder besluit of 'n regstelling vrygestel moet word op grond van die erns van die fout.
Foute wissel na gelang van hul erns. S4- of S3-foute kan dus stilisties wees, soos pixel- of ikoonverplasing. Dit is nie minder belangrik nie, maar daar is geen noemenswaardige impak op enigiemand se werkvloei nie, wat beteken dat die waarskynlikheid dat 'n oplossing vir sulke S3- of S4-foute geskep sal word, klein is, verduidelik Marin.
Kwesbaarhede S1 of S2 beteken egter dat die gebruiker nie na die nuutste weergawe moet opdateer nie, of daar is 'n beduidende fout wat die gebruiker se werkvloei beïnvloed. As hulle by die spoorsnyer ingesluit is, het baie gebruikers hulle teëgekom, so die vrystellingbestuurder begin dadelik om 'n oplossing voor te berei.
Sodra 'n pleister vir kwesbaarhede S1 of S2 gereed is, begin die vrystellingbestuurder die pleister vrystel.
Byvoorbeeld, die GitLab 12.10.1-pleister is geskep nadat verskeie blokkeringskwessies geïdentifiseer is en die ontwikkelaars die onderliggende probleem wat hulle veroorsaak het, reggestel het. Die Vrystellingbestuurder het die korrektheid van die toegewese ernsvlakke beoordeel, en na bevestiging is die proses van vrystelling van 'n regstelling van stapel gestuur, wat gereed was binne XNUMX uur nadat die blokkeringsprobleme ontdek is.
Wanneer baie S4, S3 en S2 ophoop, kyk die vrystellingbestuurder na die konteks om die dringendheid van die vrystelling van 'n regstelling te bepaal, en wanneer 'n sekere aantal daarvan bereik word, word hulle almal gekombineer en vrygestel. Na-vrystelling regstellings of sekuriteitsopdaterings word in blogplasings opgesom.
Hoe 'n vrystellingbestuurder pleisters skep
Ons gebruik GitLab CI en ander kenmerke soos ons ChatOps om pleisters te genereer. Vrystellingbestuurder begin die vrystelling van die oplossing deur die ChatOps-span op ons interne kanaal te aktiveer #releases in Slack.
/chatops run release prepare 12.10.1ChatOps werk binne Slack om verskillende gebeurtenisse te aktiveer, wat dan deur GitLab verwerk en uitgevoer word. Byvoorbeeld, die afleweringspan het ChatOps opgestel om verskeie dinge te outomatiseer om pleisters vry te stel.
Sodra die vrystellingbestuurder die ChatOps-span in Slack begin, gebeur die res van die werk outomaties in GitLab met behulp van CICD. Daar is tweerigtingkommunikasie tussen ChatOps in Slack en GitLab tydens die vrystellingsproses aangesien die vrystellingbestuurder sommige van die belangrikste stappe in die proses aktiveer.
Die video hieronder toon die tegniese proses om 'n pleister vir GitLab voor te berei.
Hoe outomatiese ontplooiing op gitlab.com werk
Die proses en gereedskap wat gebruik word om gitlab.com op te dateer is soortgelyk aan dié wat gebruik word om pleisters te skep. Die opdatering van gitlab.com verg minder handwerk vanuit die vrystellingbestuurder se oogpunt.
In plaas daarvan om implementerings met ChatOps te laat loop, gebruik ons CI-kenmerke, bv. , waarmee die vrystellingbestuurder sekere aksies kan skeduleer wat op die vereiste tyd uitgevoer moet word. In plaas van 'n handmatige proses, is daar 'n pyplyn wat periodiek een keer 'n uur loop wat die nuwe veranderinge wat aan GitLab-projekte gemaak is, aflaai, dit verpak en ontplooiing skeduleer, en outomaties toetse, QA en ander nodige stappe uitvoer.
"Ons het dus baie ontplooiings wat in verskillende omgewings loop voor gitlab.com, en nadat daardie omgewings in goeie toestand is en toetse goeie resultate toon, begin die vrystellingbestuurder die gitlab.com-ontplooiingsaksies," sê Marin.
CICD-tegnologie vir die ondersteuning van gitlab.com-opdaterings outomatiseer die hele proses tot die punt waar die vrystellingbestuurder die implementering van die produksie-omgewing handmatig na gitlab.com moet begin.
Marin gaan in detail oor die gitlab.com-opdateringsproses in die video hieronder.
Wat doen die afleweringspan nog?
Die belangrikste verskil tussen die gitlab.com-opdateringsprosesse en die vrystelling van pleisters aan kliënte in die huis is dat laasgenoemde proses meer tyd en meer handwerk van die vrystellingbestuurder vereis.
"Ons vertraag soms die vrystelling van pleisters aan kliënte met hul installasies as gevolg van gerapporteerde probleme, gereedskapkwessies, en omdat daar baie nuanses is wat in ag geneem moet word wanneer 'n enkele pleister vrygestel word," sê Marin.
Een van die korttermyndoelwitte van die afleweringspan is om die hoeveelheid handwerk aan die kant van die vrystellingbestuurder te verminder om die vrystelling te bespoedig. Die span werk daaraan om die vrystellingsproses te vereenvoudig, vaartbelyn en outomatiseer, wat sal help om regstellings te kry vir lae ernsprobleme (S3 en S4, ongeveer. vertaler). Fokus op spoed is 'n sleutelprestasie-aanwyser: dit is nodig om MTTP - die tyd vanaf die ontvangs van 'n samesmeltingsversoek tot die ontplooiing van die resultaat na gitlab.com - van die huidige 50 uur tot 8 uur te verminder.
Die afleweringspan werk ook daaraan om gitlab.com na 'n Kubernetes-gebaseerde infrastruktuur te migreer.
Redakteur se NB: As jy al van Kubernetes-tegnologie gehoor het (en ek twyfel nie daaraan nie), maar dit nog nie met jou hande aangeraak het nie, beveel ek aan om aan aanlyn intensiewe kursusse deel te neem , wat 28-30 September sal plaasvind, en , wat 14–16 Oktober sal plaasvind. Dit sal jou toelaat om met selfvertroue te navigeer en met die tegnologie te werk.
Dit is twee benaderings wat dieselfde doel nastreef: vinnige aflewering van opdaterings, beide vir gitlab.com en vir kliënte by hul fasiliteite.
Enige idees of aanbevelings vir ons?
Almal is welkom om by te dra tot GitLab, en ons verwelkom terugvoer van ons lesers. As jy enige idees vir ons afleweringspan het, moet asseblief nie huiwer nie met kennisgewing team: Delivery.
Bron: will.com