Bei GitLab veraarbechte mir Software Fixen op zwou Weeër: manuell an automatesch. Weiderliesen fir iwwer d'Aarbecht vum Verëffentlechungsmanager ze léieren fir wichteg Updates iwwer automatiséiert Deployment op gitlab.com ze kreéieren an ze liwweren, souwéi Patches fir Benotzer mat hiren eegene Installatiounen ze schaffen.
Ech recommandéieren eng Erënnerung op Ärem Smartwatch ze setzen: all Mount den 22., Benotzer, déi mat GitLab an hiren Ariichtungen schaffen, kënnen Updates vun der aktueller Versioun vun eisem Produkt gesinn. Déi monatlecht Verëffentlechung enthält nei Features, Entwécklunge vun existente, a weist dacks d'Ennresultat vu Gemeinschaftsufroe fir Tooling oder Fusioun.
Awer, wéi d'Praxis weist, ass Softwareentwécklung selten ouni Mängel. Wann e Feeler oder Sécherheetsschwaachheet entdeckt gëtt, erstellt de Verëffentlechungsmanager am Liwwerteam e Patch fir eis Benotzer mat hiren Installatiounen. Gitlab.com gëtt während dem CD Prozess aktualiséiert. Mir nennen dësen CD Prozess automatesch Deployment fir Duercherneen mat der CD Feature am GitLab ze vermeiden. Dëse Prozess kann Suggestiounen aus Pull-Ufroen, déi vu Benotzer, Clienten, an eisem internen Entwécklungsteam proposéiert goufen, integréieren, sou datt d'Léisung vum langweilege Problem fir Patches ze verëffentlechen op zwou ganz verschidde Weeër geléist gëtt.
«Mir garantéieren datt alles wat d'Entwéckler maachen all Dag an all Ëmfeld ofgesat gëtt ier se op GitLab.com rullen", erkläert , Senior Technesch Manager, Infrastruktur Departement. "Denkt un Verëffentlechungen fir Är Installatiounen als Snapshots fir gitlab.com Deployments, fir déi mir separat Schrëtt bäigefüügt hunn fir e Package ze kreéieren sou datt eis Benotzer et benotze kënnen fir op hiren Installatiounen z'installéieren".
Onofhängeg vun der Käfer oder Schwachstelle, gitlab.com Clienten kréien Fixer kuerz nodeems se publizéiert ginn, wat e Virdeel vum automatiséierte CD Prozess ass. Patches fir Benotzer mat hiren eegene Installatiounen erfuerderen separat Virbereedung vum Release Manager.
D'Liwwerteam schafft haart fir déi meescht vun de Prozesser ze automatiséieren déi an der Schafung vun Releases involvéiert sinn fir ze reduzéieren (Mëttelzäit bis Produktioun, dh Zäit fir d'Produktioun verbraucht), d'Zäit vun der Veraarbechtung vun enger Fusiounsufro vun engem Entwéckler bis zur Ofsetzung op gitlab.com.
«D'Zil vum Liwwerteam ass sécherzestellen datt mir als Firma méi séier kënne réckelen, oder op d'mannst d'Liwwerungsleit méi séier schaffen, richteg?, seet de Marin.
Béid gitlab.com Clienten an d'Benotzer vun hiren Installatiounen profitéiere vun den Efforten vum Liwwerteam fir Zykluszäiten ze reduzéieren an d'Deployementer ze beschleunegen. An dësem Artikel erkläre mir d'Ähnlechkeeten an d'Ënnerscheeder tëscht dësen zwou Methoden. , a mir wäerten och beschreiwen wéi eis Liwwerteam Patches virbereet fir Benotzer déi op hiren Ariichtungen schaffen, wéi och wéi mir garantéieren datt gitlab.com mat automateschen Deployment aktuell ass.
Wat mécht e Release Manager?
Teammemberen all Mount eis Verëffentlechungen un d'Benotzer an hiren Ariichtungen, dorënner Patches a Sécherheetsreleasen, déi tëscht Verëffentlechungen optriede kënnen. Si sinn och verantwortlech fir den Iwwergank vun der Firma op automatiséiert, kontinuéierlech Deployment ze féieren.
Selbstinstallatioun Verëffentlechungen a gitlab.com Verëffentlechungen benotzen ähnlech Workflows awer lafen zu verschiddenen Zäiten, erkläert Marin.
Éischtens a virun allem suergt de Verëffentlechungsmanager, onofhängeg vun der Verëffentlechungstyp, datt GitLab verfügbar a sécher ass vum Moment wou d'Applikatioun op gitlab.com lancéiert gëtt, inklusiv sécherzestellen datt déiselwecht Themen net an der Infrastruktur vu Cliente mat hirem eegene Kapazitéiten.
Wann e Feeler oder Schwachstelle gezeechent ass am GitLab fixéiert, muss de Verëffentlechungsmanager evaluéieren datt et an de Patches oder Sécherheetsupdates fir Benotzer mat hiren Installatiounen abegraff ass. Wann hien decidéiert datt e Feeler oder Schwachstelle en Update verdéngt, fänkt d'Virbereedungsaarbecht un.
De Verëffentlechungsmanager muss entscheeden ob e Fix preparéiert oder wéini se ofgesat gëtt - an dëst ass héich ofhängeg vum Kontext vun der Situatioun, "an der Tëschenzäit, Maschinnen sinn net esou gutt am Kontext Gestioun wéi Leit" seet Marin.
Et ass alles ëm d'Fixatiounen
Wat sinn Patches a firwat brauche mir se?
De Verëffentlechungsmanager entscheet ob e Fix verëffentlecht gëtt baséiert op der Gravitéit vum Feeler.
Feeler variéieren jee no hirer Gravitéit. Also S4 oder S3 Feeler kënne stilistesch sinn, wéi Pixel oder Ikon Verrécklung. Dëst ass net manner wichteg, awer et gëtt kee wesentlechen Impakt op iergendeen säin Workflow, dat heescht datt d'Wahrscheinlechkeet datt e Fix fir sou S3 oder S4 Feeler erstallt gëtt kleng ass, erkläert Marin.
Wéi och ëmmer, Schwachstelle S1 oder S2 bedeit datt de Benotzer net op déi lescht Versioun aktualiséieren soll, oder et gëtt e wesentleche Feeler deen de Workflow vum Benotzer beaflosst. Wann se am Tracker abegraff sinn, hu vill Benotzer se begéint, sou datt de Release Manager direkt ufänkt eng Fix ze preparéieren.
Wann e Patch fir Schwachstelle S1 oder S2 fäerdeg ass, fänkt de Release Manager de Patch eraus.
Zum Beispill, de GitLab 12.10.1 Patch gouf erstallt nodeems e puer Blockéierungsprobleemer identifizéiert goufen an d'Entwéckler de Basisdaten Thema fixéieren deen se verursaacht huet. De Verëffentlechungsmanager huet d'Korrektheet vun den zougewisenen Schwieregkeetsniveauen bewäert, an no der Bestätegung gouf de Prozess vun der Verëffentlechung vun enger Fix gestart, déi bannent XNUMX Stonnen fäerdeg war nodeems d'Blockéierungsproblemer entdeckt goufen.
Wann vill S4, S3 an S2 accumuléieren, kuckt de Verëffentlechungsmanager op de Kontext fir d'Urgence vun der Verëffentlechung vun enger Fix ze bestëmmen, a wann eng gewëssen Zuel vun hinnen erreecht gëtt, ginn se all kombinéiert a verëffentlecht. Post-Release Fixen oder Sécherheetsupdates ginn a Blogposte zesummegefaasst.
Wéi e Release Manager erstellt Patches
Mir benotzen GitLab CI an aner Funktiounen wéi eis ChatOps fir Patches ze generéieren. Release Manager fänkt d'Verëffentlechung vun der Fix un andeems d'ChatOps Team op eisem internen Kanal aktivéiert #releases an Slack.
/chatops run release prepare 12.10.1ChatOps funktionnéiert bannent Slack fir verschidden Eventer auszeléisen, déi dann vu GitLab veraarbecht an ausgefouert ginn. Zum Beispill huet d'Liwwerteam ChatOps opgeriicht fir verschidde Saachen ze automatiséieren fir Patches ze verëffentlechen.
Wann de Verëffentlechungsmanager d'ChatOps Team am Slack ufänkt, geschitt de Rescht vun der Aarbecht automatesch am GitLab mat CICD. Et gëtt zwee-Wee Kommunikatioun tëscht ChatOps am Slack a GitLab wärend dem Verëffentlechungsprozess wéi de Verëffentlechungsmanager e puer vun de grousse Schrëtt am Prozess aktivéiert.
De Video hei ënnen weist den technesche Prozess fir e Patch fir GitLab ze preparéieren.
Wéi automatesch Deployment funktionnéiert op gitlab.com
De Prozess an d'Tools déi benotzt gi fir gitlab.com ze aktualiséieren sinn ähnlech wéi déi benotzt fir Patches ze kreéieren. D'Aktualiséierung vun gitlab.com erfuerdert manner manuell Aarbecht aus der Siicht vum Release Manager.
Amplaz vun Détachementer mat ChatOps auszeféieren, benotze mir CI Funktiounen z.B. , mat deem de Verëffentlechungsmanager bestëmmten Aktiounen plangen, déi zu der erfuerderter Zäit ausgefouert ginn. Amplaz vun engem manuelle Prozess gëtt et eng Pipeline déi periodesch eemol d'Stonn leeft, déi déi nei Ännerunge fir GitLab Projeten eroflueden, se packt an d'Deployment plangt, an automatesch Testen, QA an aner noutwendeg Schrëtt ausféiert.
"Also hu mir vill Deployementer, déi a verschiddenen Ëmfeld viru gitlab.com lafen, an nodeems dës Ëmfeld a gudder Form sinn an Tester gutt Resultater weisen, fänkt de Verëffentlechungsmanager d'gitlab.com Deployment Aktiounen un," seet Marin.
CICD Technologie fir d'Ënnerstëtzung vun gitlab.com Updates automatiséiert de ganze Prozess op de Punkt wou de Verëffentlechungsmanager manuell d'Deployment vun der Produktiounsëmfeld op gitlab.com lancéiere muss.
De Marin geet am Detail iwwer de gitlab.com Update Prozess am Video hei ënnen.
Wat soss mécht d'Liwwerteam?
Den Haaptunterschied tëscht de gitlab.com Update Prozesser an d'Verëffentlechung vu Patches fir Clienten intern ass datt de leschte Prozess méi Zäit a méi manuell Aarbecht vum Release Manager erfuerdert.
"Mir verspéiten heiansdo d'Verëffentlechung vu Patches fir Clienten mat hiren Installatiounen wéinst gemellten Themen, Toolingprobleemer, a well et vill Nuancen sinn, déi musse berücksichtegt ginn wann Dir en eenzege Patch verëffentlecht", seet de Marin.
Ee vun de kuerzfristeg Ziler vum Liwwerteam ass d'Quantitéit vun der manueller Aarbecht vum Deel vum Release Manager ze reduzéieren fir d'Verëffentlechung ze beschleunegen. D'Team schafft fir de Verëffentlechungsprozess ze vereinfachen, ze streamlinéieren an ze automatiséieren, wat hëlleft Fixe fir Probleemer mat niddereger Schwieregkeet (S3 a S4, ca. Iwwersetzer). Schwéierpunkt op Geschwindegkeet ass e Schlësselleistungsindikator: et ass néideg MTTP ze reduzéieren - d'Zäit vun der Empfang vun enger Fusiounsufro bis d'Resultat op gitlab.com z'installéieren - vun den aktuellen 50 Stonnen op 8 Stonnen.
D'Liwwerteam schafft och un der Migratioun gitlab.com op eng Kubernetes-baséiert Infrastruktur.
Redakter NB: Wann Dir schonn iwwer Kubernetes Technologie héieren hutt (an ech hunn keen Zweiwel datt Dir hutt), awer Dir hutt et nach net mat Ären Hänn beréiert, ech recommandéieren un online intensiv Coursen deelzehuelen , déi stattfënnt 28-30 September, an , déi vum 14.-16. Oktober stattfënnt. Dëst erlaabt Iech zouversiichtlech mat der Technologie ze navigéieren an ze schaffen.
Dëst sinn zwou Approche déi datselwecht Zil verfollegen: séier Liwwerung vun Updates, souwuel fir gitlab.com wéi och fir Clienten an hiren Ariichtungen.
All Iddien oder Empfehlungen fir eis?
Jiddereen ass wëllkomm op GitLab bäizedroen, a mir begréissen Feedback vun eise Lieser. Wann Dir Iddie fir eis Liwwerteam hutt, zéckt net mat Notiz team: Delivery.
Source: will.com