By GitLab ferwurkje wy softwarefixes op twa manieren: manuell en automatysk. Lês fierder om te learen oer de taak fan 'e release manager fan it meitsjen en leverjen fan wichtige updates fia automatisearre ynset nei gitlab.com, lykas patches foar brûkers om mei te wurkjen oan har eigen ynstallaasjes.
Ik advisearje it ynstellen fan in herinnering op jo smartwatch: elke moanne op 'e 22e kinne brûkers dy't wurkje mei GitLab op har fasiliteiten updates sjen foar de hjoeddeistige ferzje fan ús produkt. De moanlikse release befettet nije funksjes, ûntjouwings fan besteande, en toant faak it einresultaat fan oanfragen fan 'e mienskip foar tooling of fúzjes.
Mar, lykas de praktyk lit sjen, is softwareûntwikkeling selden sûnder gebreken. As in brek of kwetsberens foar feiligens wurdt ûntdutsen, makket de releasebehearder yn it leveringsteam in patch foar ús brûkers mei har ynstallaasjes. Gitlab.com wurdt bywurke tidens it CD-proses. Wy neame dit CD-proses automatyske ynset om betizing te foarkommen mei de CD-funksje yn GitLab. Dit proses kin suggestjes opnimme fan pull-oanfragen yntsjinne troch brûkers, klanten en ús ynterne ûntwikkelingsteam, sadat it oplossen fan it saaie probleem fan it frijjaan fan patches op twa heul ferskillende manieren oplost wurdt.
«Wy soargje derfoar dat alles wat ûntwikkelders meitsje elke dei wurdt ynset yn alle omjouwings foardat it útrolt nei GitLab.com", ferklearret , Senior Technysk Manager, Ynfrastruktuer ôfdieling. "Tink oan releases foar jo ynstallaasjes as snapshots foar gitlab.com-ynset, wêrfoar wy aparte stappen tafoege hawwe om in pakket te meitsjen sadat ús brûkers it kinne brûke om te ynstallearjen op har ynstallaasjes".
Nettsjinsteande de brek of kwetsberens, gitlab.com-klanten sille koart nei't se publisearre binne reparaasjes krije, wat in foardiel is fan it automatisearre CD-proses. Patches foar brûkers mei har eigen ynstallaasjes fereaskje aparte tarieding troch de release manager.
It leveringsteam wurket hurd om de measte prosessen te automatisearjen dy't belutsen binne by it meitsjen fan releases om te ferminderjen (gemiddelde tiid oant produksje, d.w.s. tiid bestege oan produksje), de tiidperioade fan it ferwurkjen fan in fúzjefersyk troch in ûntwikkelder oant ynset op gitlab.com.
«It doel fan it leveringsteam is om derfoar te soargjen dat wy as bedriuw rapper kinne bewegen, of op syn minst de leveringsminsken rapper wurkje kinne, krekt?, seit Marin.
Sawol gitlab.com-klanten as brûkers fan har ynstallaasjes profitearje fan de ynspanningen fan it leveringsteam om syklustiden te ferminderjen en ynset te fersnellen. Yn dit artikel sille wy de oerienkomsten en ferskillen tusken dizze twa metoaden útlizze. , en wy sille ek beskriuwe hoe't ús levering team tariedt patches foar brûkers dy't rinne on-site, en hoe't wy hâlden gitlab.com aktueel mei help fan automatisearre ynset.
Wat docht in release manager?
Teamleden alle moannen ús releases oan brûkers op harren foarsjennings, ynklusyf patches en feiligens releases dy't kinne foarkomme tusken releases. Se binne ek ferantwurdlik foar it lieden fan de oergong fan it bedriuw nei automatisearre, trochgeande ynset.
Self-ynstallaasje releases en gitlab.com releases brûke ferlykbere workflows mar rinne op ferskillende tiden, Marin leit út.
Earst en foaral soarget de releasebehearder, nettsjinsteande it releasetype, dat GitLab beskikber en feilich is fanôf it momint dat de applikaasje op gitlab.com wurdt lansearre, ynklusyf it garandearjen dat deselde problemen net einigje yn 'e ynfrastruktuer fan klanten mei har eigen kapasiteiten.
Sadree't in brek of kwetsberens is markearre fêst yn GitLab, de release manager moat evaluearje dat it sil wurde opnaam yn de patches of feiligens updates foar brûkers mei harren ynstallaasjes. As hy beslút dat in brek of kwetsberens in update fertsjinnet, begjint it tariedende wurk.
De frijlittingsbehearder moat beslute oft in fix tariede, of wannear't it moat wurde ynset - en dit is heul ôfhinklik fan 'e kontekst fan' e situaasje, "yn 'e tuskentiid, masines binne net sa goed op behear kontekst as minsken" seit Marin.
It giet allegear oer de reparaasjes
Wat binne patches en wêrom hawwe wy se nedich?
De releasebehearder beslút oft in fix frijlitten wurdt op basis fan 'e earnst fan' e brek.
Flaters ferskille ôfhinklik fan har earnst. Sa kinne S4- of S3-flaters stilistysk wêze, lykas piksel- of ikoanferpleatsing. Dit is net minder wichtich, mar d'r is gjin signifikante ynfloed op 'e workflow fan ien, wat betsjut dat de kâns dat in fix sil wurde makke foar sokke S3- of S4-flaters lyts is, ferklearret Marin.
De kwetsberens S1 of S2 betsjutte lykwols dat de brûker net moat bywurkje nei de lêste ferzje, of d'r is in wichtige brek dy't ynfloed hat op de workflow fan 'e brûker. As se binne opnommen yn 'e tracker, hawwe in protte brûkers se tsjinkaam, sadat de releasebehearder fuortendaliks begjint mei it tarieden fan in fix.
Sadree't in patch foar kwetsberens S1 of S2 klear is, begjint de releasebehearder de patch frij te litten.
Bygelyks, de GitLab 12.10.1 patch waard makke neidat ferskate blokkearjende problemen waarden identifisearre en de ûntwikkelders repareare it ûnderlizzende probleem dat har feroarsake. De Release-manager beoardiele de krektens fan 'e tawiisde hurdensnivo's, en nei befêstiging waard it proses fan it frijlitten fan in fix lansearre, dy't klear wie binnen XNUMX oeren nei't de blokkearjende problemen waarden ûntdutsen.
As in protte S4, S3 en S2 accumulearje, besjocht de releasebehearder de kontekst om de urginsje fan it frijlitten fan in fix te bepalen, en as in bepaald oantal fan har wurdt berikt, wurde se allegear kombineare en frijlitten. Post-release fixes of feiligens updates wurde gearfette yn blog berjochten.
Hoe in release manager makket patches
Wy brûke GitLab CI en oare funksjes lykas ús ChatOps om patches te generearjen. Release manager triggert de frijlitting fan 'e fix troch it aktivearjen fan it ChatOps-team op ús ynterne kanaal #releases yn Slach.
/chatops run release prepare 12.10.1ChatOps wurket binnen Slack om ferskate eveneminten te triggerjen, dy't dan wurde ferwurke en útfierd troch GitLab. Bygelyks, it leveringsteam hat ChatOps ynsteld om ferskate dingen te automatisearjen om patches frij te litten.
Sadree't de releasebehearder it ChatOps-team yn Slack begjint, bart de rest fan it wurk automatysk yn GitLab mei CICD. D'r is twa-wei kommunikaasje tusken ChatOps yn Slack en GitLab tidens it frijlittingsproses, om't de releasebehearder guon fan 'e wichtichste stappen yn it proses aktivearret.
De fideo hjirûnder toant it technyske proses fan it tarieden fan in patch foar GitLab.
Hoe automatyske ynset wurket op gitlab.com
It proses en de ark brûkt om gitlab.com te aktualisearjen binne fergelykber mei dy brûkt om patches te meitsjen. It bywurkjen fan gitlab.com fereasket minder hânwurk út it eachpunt fan 'e releasebehearder.
Ynstee fan it útfieren fan ynset mei ChatOps, brûke wy CI-funksjes bgl. , wêrmei't de releasebehearder bepaalde aksjes planne kin om op 'e fereaske tiid út te fieren. Yn stee fan in hânmjittich proses is d'r in pipeline dy't periodyk ien kear yn 't oere rint dy't nije wizigingen downloade oan GitLab-projekten, pakke se en plannen ynset, en automatysk testen, QA en oare nedige stappen útfiert.
"Dat wy hawwe in protte ynset dy't rinne yn ferskate omjouwings foar gitlab.com, en nei't dy omjouwings yn goede foarm binne en testen goede resultaten sjen litte, begjint de releasemanager de gitlab.com-ynsetaksjes," seit Marin.
CICD-technology foar it stypjen fan gitlab.com-updates automatisearret it heule proses oant it punt wêr't de releasebehearder de ynset fan 'e produksjeomjouwing manuell moat starte nei gitlab.com.
Marin giet yn detail oer it gitlab.com-fernijingsproses yn 'e fideo hjirûnder.
Wat docht it leveringsteam oars?
It wichtichste ferskil tusken de gitlab.com-updateprosessen en it frijjaan fan patches oan klanten yn eigen hûs is dat it lêste proses mear tiid en mear hânwurk fereasket fan 'e releasemanager.
"Wy fertrage soms it frijlitten fan patches oan klanten mei har ynstallaasjes fanwege rapporteare problemen, arkproblemen, en om't d'r in protte nuânses binne dy't rekken holden wurde moatte by it frijjaan fan in inkele patch," seit Marin.
Ien fan 'e koarte termyn doelen fan it leveringsteam is om de hoemannichte hânwurk fan' e kant fan 'e releasemanager te ferminderjen om de frijlitting te fersnellen. It team wurket oan it ferienfâldigjen, streamlynjen en automatisearjen fan it frijlittingsproses, wat sil helpe reparaasjes te krijen foar problemen mei lege earnst (S3 en S4, ca. oersetter). Fokus op snelheid is in wichtige prestaasje-yndikator: it is needsaaklik om MTTP - de tiid fan it ûntfangen fan in fúzjefersyk oant it ynsetten fan it resultaat nei gitlab.com - te ferminderjen fan 'e hjoeddeistige 50 oeren nei 8 oeren.
It leveringsteam wurket ek oan it migrearjen fan gitlab.com nei in Kubernetes-basearre ynfrastruktuer.
Redaksje n.b.: As jo al heard hawwe oer Kubernetes-technology (en ik ha gjin twifel dat jo hawwe), mar it noch net mei jo hannen oanrekke hawwe, ried ik oan om diel te nimmen oan online yntinsive kursussen , dat wurdt holden 28-30 septimber, en , dy't plakfine sil fan 14-16 oktober. Hjirmei kinne jo mei fertrouwen navigearje en wurkje mei de technology.
Dit binne twa oanpakken dy't itselde doel stribjen: snelle levering fan updates, sawol foar gitlab.com as foar kliïnten by har foarsjenningen.
Guon ideeën of oanbefellings foar ús?
Elkenien is wolkom om by te dragen oan GitLab, en wy ferwolkomje feedback fan ús lêzers. As jo ideeën hawwe foar ús leveringsteam, aarzel dan net mei notice team: Delivery.
Boarne: www.habr.com