Ĉe GitLab, ni prilaboras programajn korektojn en du manieroj: permane kaj aŭtomate. Legu plu por lerni pri la tasko de la eldonmanaĝero krei kaj liveri gravajn ĝisdatigojn per aŭtomatigita deplojo al gitlab.com, kaj ankaŭ flikojn por uzantoj por labori pri siaj propraj instalaĵoj.
Mi rekomendas agordi memorigilon sur via inteligenta horloĝo: ĉiumonate la 22-an, uzantoj laborantaj kun GitLab ĉe siaj instalaĵoj povas vidi ĝisdatigojn al la nuna versio de nia produkto. La monata eldono enhavas novajn funkciojn, evoluojn de ekzistantaj, kaj ofte montras la finan rezulton de komunumaj petoj pri ilado aŭ kunfando.
Sed, kiel praktiko montras, programaro malofte estas sen difektoj. Kiam cimo aŭ sekureca vundebleco estas malkovrita, la eldona administranto en la liverteamo kreas diakilon por niaj uzantoj kun iliaj instalaĵoj. Gitlab.com estas ĝisdatigita dum la KD-procezo. Ni nomas ĉi tiun KD-procezon aŭtomata deplojo por eviti konfuzon kun la KD-trajto en GitLab. Ĉi tiu procezo povas enkorpigi sugestojn de tiraj petoj senditaj de uzantoj, klientoj kaj nia interna evolua teamo, tiel ke solvi la enuigan problemon de liberigo de flikaĵoj estas solvita en du tre malsamaj manieroj.
«Ni certigas, ke ĉio, kion faras programistoj, estas deplojita al ĉiuj medioj ĉiutage antaŭ ol eldoni ĝin al GitLab.com.", klarigas , Senior Technical Manager, Infrastructure Department. "Pensu pri eldonoj por viaj instalaĵoj kiel momentfotoj por gitlab.com-deplojoj, por kiuj ni aldonis apartajn paŝojn por krei pakaĵon por ke niaj uzantoj povu uzi ĝin por instali en siaj instalaĵoj.".
Sendepende de la cimo aŭ vundebleco, gitlab.com-klientoj ricevos korektojn baldaŭ post kiam ili estos publikigitaj, kio estas avantaĝo de la aŭtomata KD-procezo. Flikiloj por uzantoj kun siaj propraj instalaĵoj postulas apartan preparadon de la eldonmanaĝero.
La livera teamo laboras forte por aŭtomatigi la plej multajn el la procezoj implikitaj en kreado de eldonoj por redukti (averaĝa tempo ĝis produktado, t.e. tempo elspezita por produktado), la tempodaŭro de prilaborado de kunfanda peto de programisto ĝis deplojo ĉe gitlab.com.
«La celo de la liverteamo estas certigi, ke ni povas moviĝi pli rapide kiel kompanio, aŭ almenaŭ igi la liverantojn labori pli rapide, ĝuste.?, diras Marin.
Kaj klientoj de gitlab.com kaj uzantoj de siaj instalaĵoj profitas el la klopodoj de la liverteamo por redukti ciklotempojn kaj akceli deplojojn. En ĉi tiu artikolo ni klarigos la similecojn kaj diferencojn inter ĉi tiuj du metodoj. , kaj ni ankaŭ priskribos kiel nia liverteamo preparas flikojn por uzantoj kurantaj surloke, kaj kiel ni tenas gitlab.com ĝisdatigita uzante aŭtomatan deplojon.
Kion faras eldonadministranto?
Teamanoj ĉiumonate niaj eldonoj al uzantoj ĉe iliaj instalaĵoj, inkluzive de flikaĵoj kaj sekurecaj eldonoj, kiuj povas okazi inter eldonoj. Ili ankaŭ respondecas pri gvidado de la transiro de la firmao al aŭtomata, kontinua deplojo.
Mem-instalaj eldonoj kaj gitlab.com-eldonoj uzas similajn laborfluojn sed funkcias en malsamaj tempoj, Marin klarigas.
Unue kaj ĉefe, la eldonmanaĝero, sendepende de la eldontipo, certigas, ke GitLab estas disponebla kaj sekura de la momento, kiam la aplikaĵo estas lanĉita sur gitlab.com, inkluzive de certigi, ke la samaj problemoj ne finiĝas en la infrastrukturo de klientoj kun siaj. propraj kapabloj.
Post kiam cimo aŭ vundebleco estas markita kiel fiksita en GitLab, la eldona administranto devas taksi, ke ĝi estos inkluzivita en la flikoj aŭ sekurecaj ĝisdatigoj por uzantoj kun iliaj instalaĵoj. Se li decidas, ke cimo aŭ vundebleco meritas ĝisdatigon, komenciĝas la prepara laboro.
La eldonmanaĝero devas decidi ĉu prepari solvon, aŭ kiam deploji ĝin - kaj tio tre dependas de la kunteksto de la situacio, "intertempe, maŝinoj ne tiom kapablas administri kuntekston kiel homoj" diras Marin.
Ĉio temas pri la korektoj
Kio estas flikiloj kaj kial ni bezonas ilin?
La eldonadministranto decidas ĉu liberigi solvon bazitan sur la severeco de la cimo.
Eraroj varias laŭ ilia severeco. Do S4 aŭ S3-eraroj povas esti stilaj, kiel pikselo aŭ ikono-movo. Ĉi tio ne estas malpli grava, sed ne estas grava efiko sur la laborfluo de iu ajn, kio signifas, ke la verŝajneco, ke riparo estos kreita por tiaj S3 aŭ S4-eraroj, estas malgranda, klarigas Marin.
Tamen, vundeblecoj S1 aŭ S2 signifas, ke la uzanto ne devas ĝisdatigi al la plej nova versio, aŭ ekzistas grava cimo, kiu influas la laborfluon de la uzanto. Se ili estas inkluzivitaj en la spurilo, multaj uzantoj renkontis ilin, do la eldonadministranto tuj komencas prepari solvon.
Post kiam flikaĵo por vundeblecoj S1 aŭ S2 estas preta, la eldona administranto komencas liberigi la diakilon.
Ekzemple, la diakilo GitLab 12.10.1 estis kreita post kiam pluraj blokaj problemoj estis identigitaj kaj la programistoj riparis la suban problemon, kiu kaŭzis ilin. La Release-manaĝero taksis la ĝustecon de la asignitaj severeco-niveloj, kaj post konfirmo, la procezo de liberigo de solvo estis lanĉita, kiu estis preta ene de XNUMX horoj post kiam la blokado de problemoj estis malkovritaj.
Kiam amasiĝas multe da S4, S3 kaj S2, la eldona administranto rigardas la kuntekston por determini la urĝecon liberigi riparadon, kaj kiam certa nombro da ili estas atingita, ili ĉiuj estas kombinitaj kaj liberigitaj. Post-eldonaj korektoj aŭ sekurecaj ĝisdatigoj estas resumitaj en blogaj afiŝoj.
Kiel eldonadministranto kreas diakilojn
Ni uzas GitLab CI kaj aliajn funkciojn kiel niaj ChatOps por generi diakilojn. Eldonadministranto komencas la liberigon de la riparo aktivigante la ChatOps-teamon sur nia interna kanalo #releases en Slack.
/chatops run release prepare 12.10.1ChatOps funkcias ene de Slack por ekigi malsamajn eventojn, kiuj tiam estas prilaboritaj kaj efektivigitaj de GitLab. Ekzemple, la livera teamo starigis ChatOps por aŭtomatigi diversajn aferojn por liberigi diakilojn.
Post kiam la eldona administranto komencas la ChatOps-teamon en Slack, la resto de la laboro okazas aŭtomate en GitLab uzante CICD. Estas dudirekta komunikado inter ChatOps en Slack kaj GitLab dum la eldonprocezo ĉar la eldona administranto aktivigas kelkajn el la ĉefaj paŝoj en la procezo.
La suba video montras la teknikan procezon prepari diakilon por GitLab.
Kiel aŭtomata deplojo funkcias ĉe gitlab.com
La procezo kaj iloj uzataj por ĝisdatigi gitlab.com estas similaj al tiuj uzataj por krei diakilojn. Ĝisdatigi gitlab.com postulas malpli da manlaboro el la vidpunkto de la eldonmanaĝero.
Anstataŭ ruli deplojojn uzante ChatOps, ni uzas CI-funkciojn ekz. , kun kiu la eldonmanaĝero povas plani certajn agojn por esti faritaj je la bezonata tempo. Anstataŭ mana procezo, ekzistas dukto, kiu periode funkcias unufoje hore, kiu elŝutas la novajn ŝanĝojn faritajn al GitLab-projektoj, pakas ilin kaj planas deplojon, kaj aŭtomate funkcias testadon, QA kaj aliajn necesajn paŝojn.
"Do ni havas multajn deplojojn kurantajn en malsamaj medioj antaŭ gitlab.com, kaj post kiam tiuj medioj estas en bona formo kaj testado montras bonajn rezultojn, la eldona administranto komencas la deplojajn agojn de gitlab.com," diras Marin.
CICD-teknologio por subteni ĝisdatigojn de gitlab.com aŭtomatigas la tutan procezon ĝis la punkto, kie la eldonmanaĝero devas permane lanĉi la disfaldiĝon de la produktadmedio al gitlab.com.
Marin eniras en detalojn pri la ĝisdatigo de gitlab.com en la suba video.
Kion alian faras la liverteamo?
La ĉefa diferenco inter la ĝisdatigaj procezoj de gitlab.com kaj liberigado de diakiloj al klientoj endome estas, ke ĉi-lasta procezo postulas pli da tempo kaj pli da manlaboro de la eldona administranto.
"Ni kelkfoje prokrastas liberigi diakilojn al klientoj kun siaj instalaĵoj pro raportitaj problemoj, ilaj problemoj, kaj ĉar estas multaj nuancoj, kiujn oni devas konsideri kiam vi liberigas ununuran diakilon," diras Marin.
Unu el la mallongperspektivaj celoj de la liverteamo estas redukti la kvanton de mana laboro fare de la eldonadministranto por akceli la liberigon. La teamo laboras por simpligi, simpligi kaj aŭtomatigi la eldonprocezon, kio helpos ricevi korektojn al malaltgravaj problemoj (S3 kaj S4, ĉ. tradukisto). Fokigi rapidecon estas ŝlosila agado-indikilo: necesas redukti MTTP - la tempon de ricevado de kunfanda peto ĝis deplojado de la rezulto al gitlab.com - de la nunaj 50 horoj ĝis 8 horoj.
La livera teamo ankaŭ laboras pri migrado de gitlab.com al infrastrukturo bazita en Kubernetes.
Redaktoro n.b.: Se vi jam aŭdis pri Kubernetes-teknologio (kaj mi ne dubas, ke vi), sed ankoraŭ ne tuŝis ĝin per viaj manoj, mi rekomendas partopreni interretajn intensajn kursojn. , kiu okazos 28-30 septembro, kaj , kiu okazos 14–16 oktobron. Ĉi tio permesos vin memfide navigi kaj labori kun la teknologio.
Ĉi tiuj estas du aliroj, kiuj celas la saman celon: rapida livero de ĝisdatigoj, kaj por gitlab.com kaj por klientoj ĉe siaj instalaĵoj.
Ĉu iuj ideoj aŭ rekomendoj por ni?
Ĉiuj bonvenas kontribui al GitLab, kaj ni bonvenigas komentojn de niaj legantoj. Se vi havas ideojn por nia livera teamo, ne hezitu kun avizo team: Delivery.
fonto: www.habr.com