Jinsi tunavyotoa viraka vya programu katika GitLab

Jinsi tunavyotoa viraka vya programu katika GitLab

Katika GitLab, tunachakata urekebishaji wa programu kwa njia mbili: kwa mikono na kiotomatiki. Soma ili upate maelezo zaidi kuhusu kazi ya msimamizi wa toleo ya kuunda na kuwasilisha masasisho muhimu kupitia utumaji kiotomatiki kwa gitlab.com, pamoja na viraka kwa watumiaji kufanya kazi nazo kwenye usakinishaji wao wenyewe.

Ninapendekeza uweke kikumbusho kwenye saa yako mahiri: kila mwezi tarehe 22, watumiaji wanaofanya kazi na GitLab kwenye vituo vyao wanaweza kuona masasisho ya toleo la sasa la bidhaa zetu. Toleo la kila mwezi lina vipengele vipya, maendeleo ya vilivyopo, na mara nyingi huonyesha matokeo ya mwisho ya maombi ya jumuiya ya zana au kuunganishwa.

Lakini, kama inavyoonyesha mazoezi, ukuzaji wa programu mara chache hauna dosari. Wakati hitilafu au athari ya usalama inapogunduliwa, msimamizi wa toleo katika timu ya uwasilishaji huunda kiraka kwa watumiaji wetu na usakinishaji wao. Gitlab.com inasasishwa wakati wa mchakato wa CD. Tunauita mchakato huu wa CD kupelekwa kiotomatiki ili kuzuia kuchanganyikiwa na kipengele cha CD katika GitLab. Mchakato huu unaweza kujumuisha mapendekezo kutoka kwa maombi ya kuvuta yaliyowasilishwa na watumiaji, wateja, na timu yetu ya maendeleo ya ndani, ili kutatua tatizo la kuchosha la kutoa viraka kutatuliwa kwa njia mbili tofauti.

Β«Tunahakikisha kuwa kila kitu ambacho wasanidi hutengeneza kinatumwa kwa mazingira yote kila siku kabla ya kukisambaza kwa GitLab.com", anaelezea Marin Jankovki, Meneja Mwandamizi wa Ufundi, Idara ya Miundombinu. "Fikiria matoleo ya usakinishaji wako kama picha za uwekaji wa gitlab.com, ambazo tumeongeza hatua tofauti za kuunda kifurushi ili watumiaji wetu waweze kukitumia kusakinisha kwenye usakinishaji wao.'.

Bila kujali hitilafu au athari, wateja wa gitlab.com watapokea marekebisho muda mfupi baada ya kuchapishwa, ambayo ni faida ya mchakato wa otomatiki wa CD. Viraka kwa watumiaji walio na usakinishaji wao huhitaji maandalizi tofauti na kidhibiti cha toleo.

Timu ya uwasilishaji inafanya kazi kwa bidii ili kurekebisha michakato mingi inayohusika katika kuunda matoleo ili kupunguza MTTP (wakati wa kutayarisha uzalishaji, yaani, muda unaotumika kwenye uzalishaji), kipindi cha kuanzia kuchakata ombi la kuunganisha la msanidi programu hadi kupelekwa kwenye gitlab.com.

Β«Lengo la timu ya uwasilishaji ni kuhakikisha kuwa tunaweza kufanya kazi haraka zaidi kama kampuni, au angalau kufanya watu wanaosafirisha wafanye kazi haraka, sawa.?, anasema Marin.

Wateja wa gitlab.com na watumiaji wa usakinishaji wao hunufaika kutokana na juhudi za timu ya uwasilishaji kupunguza muda wa mzunguko na kuongeza kasi ya utumaji. Katika makala hii tutaelezea kufanana na tofauti kati ya njia hizi mbili. mambo, na pia tutaelezea jinsi timu yetu ya uwasilishaji inavyotayarisha viraka kwa watumiaji wanaofanya kazi kwenye vifaa vyao, na pia jinsi tunavyohakikisha kuwa gitlab.com imesasishwa kwa kutumia utumaji kiotomatiki.

Msimamizi wa kutolewa hufanya nini?

Washiriki wa timu kila mwezi kuhamisha jukumu la meneja wa kutolewa matoleo yetu kwa watumiaji kwenye vituo vyao, ikijumuisha viraka na matoleo ya usalama ambayo yanaweza kutokea kati ya matoleo. Pia wana jukumu la kuongoza mpito wa kampuni hadi utumaji wa kiotomatiki, unaoendelea.

Matoleo ya usakinishaji wa kibinafsi na matoleo ya gitlab.com hutumia utiririshaji wa kazi sawa lakini huendeshwa kwa nyakati tofauti, Marin anaelezea.

Kwanza kabisa, msimamizi wa toleo, bila kujali aina ya toleo, anahakikisha kuwa GitLab inapatikana na salama kutoka wakati programu inazinduliwa kwenye gitlab.com, ikiwa ni pamoja na kuhakikisha kuwa masuala sawa hayaishii katika miundombinu ya wateja na wao. uwezo wenyewe.

Pindi tu hitilafu au uwezekano wa kuathiriwa unapowekwa alama kuwa thabiti katika GitLab, kidhibiti cha toleo lazima atathmini kuwa kitajumuishwa kwenye viraka au masasisho ya usalama kwa watumiaji walio na usakinishaji wao. Ikiwa ataamua kuwa hitilafu au udhaifu unastahili kusasishwa, kazi ya maandalizi huanza.

Msimamizi wa toleo lazima aamue ikiwa atatayarisha urekebishaji, au wakati wa kupeleka - na hii inategemea sana muktadha wa hali hiyo,"kwa sasa, mashine si nzuri katika kudhibiti muktadha kama watu"anasema Marin.

Yote ni kuhusu marekebisho

Viraka ni nini na kwa nini tunazihitaji?

Kidhibiti cha toleo huamua kama kutoa marekebisho kulingana na ukali wa hitilafu.

Makosa hutofautiana kulingana na ukali wao. Kwa hivyo hitilafu za S4 au S3 zinaweza kuwa za kimtindo, kama vile uhamishaji wa pikseli au ikoni. Hii sio muhimu sana, lakini hakuna athari kubwa kwa mtiririko wa kazi wa mtu yeyote, ambayo inamaanisha kuwa uwezekano kwamba marekebisho yataundwa kwa makosa kama hayo ya S3 au S4 ni ndogo, anaelezea Marin.

Hata hivyo, udhaifu wa S1 au S2 unamaanisha kuwa mtumiaji hapaswi kusasisha hadi toleo jipya zaidi, au kuna hitilafu kubwa inayoathiri utendakazi wa mtumiaji. Ikiwa zimejumuishwa kwenye kifuatiliaji, watumiaji wengi wamekutana nao, kwa hivyo msimamizi wa kutolewa huanza kuandaa urekebishaji mara moja.

Mara kiraka cha udhaifu S1 au S2 kinapokuwa tayari, kidhibiti cha toleo kitaanza kutoa kiraka.

Kwa mfano, kiraka cha GitLab 12.10.1 kiliundwa baada ya masuala kadhaa ya kuzuia kutambuliwa na wasanidi wakarekebisha suala la msingi lililokuwa likisababisha. Msimamizi wa Kutolewa alitathmini usahihi wa viwango vya ukali vilivyowekwa, na baada ya uthibitisho, mchakato wa kutolewa kwa kurekebisha ulizinduliwa, ambao ulikuwa tayari ndani ya masaa XNUMX baada ya matatizo ya kuzuia kugunduliwa.

Wakati S4, S3 na S2 nyingi hujilimbikiza, msimamizi wa kutolewa huangalia muktadha ili kuamua uharaka wa kutolewa kwa kurekebisha, na wakati idadi fulani yao inafikiwa, zote zinaunganishwa na kutolewa. Marekebisho ya baada ya toleo au masasisho ya usalama yanafupishwa katika machapisho ya blogu.

Jinsi meneja wa kutolewa huunda viraka

Tunatumia GitLab CI na vipengele vingine kama ChatOps zetu kutengeneza viraka. Kidhibiti cha matoleo huanza kutoa marekebisho kwa kuwezesha timu ya ChatOps kwenye kituo chetu cha ndani #releases katika Slack.

/chatops run release prepare 12.10.1

ChatOps hufanya kazi ndani ya Slack ili kuanzisha matukio tofauti, ambayo huchakatwa na kutekelezwa na GitLab. Kwa mfano, timu ya uwasilishaji ilianzisha ChatOps ili kugeuza mambo kiotomatiki ili kutoa viraka.

Mara tu msimamizi wa toleo anapoanzisha timu ya ChatOps katika Slack, kazi iliyosalia hufanyika kiotomatiki kwenye GitLab kwa kutumia CICD. Kuna mawasiliano ya pande mbili kati ya ChatOps katika Slack na GitLab wakati wa mchakato wa kutoa huku kidhibiti cha toleo kikiwezesha baadhi ya hatua kuu katika mchakato.

Video hapa chini inaonyesha mchakato wa kiufundi wa kuandaa kiraka cha GitLab.

Jinsi uwekaji otomatiki unavyofanya kazi kwenye gitlab.com

Mchakato na zana zinazotumiwa kusasisha gitlab.com ni sawa na zile zinazotumiwa kuunda viraka. Kusasisha gitlab.com kunahitaji kazi ndogo ya mikono kutoka kwa mtazamo wa msimamizi wa toleo.

Badala ya kutekeleza utumaji kwa kutumia ChatOps, tunatumia vipengele vya CI k.m. mabomba yaliyopangwa, ambayo meneja wa kutolewa anaweza kuratibu vitendo fulani kufanywa kwa wakati unaohitajika. Badala ya mchakato wa mwongozo, kuna bomba ambalo huendeshwa mara kwa mara mara moja kwa saa ambalo hupakua mabadiliko mapya yaliyofanywa kwa miradi ya GitLab, hupakia na kupanga uwekaji, na huendesha majaribio kiotomatiki, QA na hatua zingine muhimu.

"Kwa hivyo tuna utumaji mwingi unaoendeshwa katika mazingira tofauti kabla ya gitlab.com, na baada ya mazingira hayo kuwa katika hali nzuri na upimaji unaonyesha matokeo mazuri, meneja wa kutolewa anaanza vitendo vya kusambaza gitlab.com," anasema Marin.

Teknolojia ya CICD ya kusaidia masasisho ya gitlab.com husasisha mchakato mzima kiotomatiki hadi ambapo msimamizi wa toleo lazima azindue mwenyewe utumaji wa mazingira ya uzalishaji kwa gitlab.com.

Marin anaingia kwa undani juu ya mchakato wa kusasisha gitlab.com kwenye video hapa chini.

Je, timu ya utoaji hufanya nini?

Tofauti kuu kati ya michakato ya kusasisha gitlab.com na kutoa viraka kwa wateja wa ndani ni kwamba mchakato wa mwisho unahitaji muda zaidi na kazi zaidi ya mikono kutoka kwa msimamizi wa toleo.

"Wakati mwingine tunachelewesha kutoa viraka kwa wateja walio na usakinishaji wao kwa sababu ya maswala yaliyoripotiwa, maswala ya zana, na kwa sababu kuna nuances nyingi ambazo zinahitaji kuzingatiwa wakati wa kutoa kiraka kimoja," anasema Marin.

Moja ya malengo ya muda mfupi ya timu ya utoaji ni kupunguza kiasi cha kazi ya mwongozo kwa upande wa meneja wa kutolewa ili kuharakisha kutolewa. Timu inajitahidi kurahisisha, kurahisisha, na kubinafsisha mchakato wa kutoa, ambao utasaidia kupata marekebisho ya masuala ya ukali wa chini (S3 na S4, takriban. mfasiri) Kuzingatia kasi ni kiashiria muhimu cha utendaji: ni muhimu kupunguza MTTP - muda kutoka kwa kupokea ombi la kuunganisha hadi kupeleka matokeo kwa gitlab.com - kutoka saa 50 za sasa hadi saa 8.

Timu ya uwasilishaji pia inafanya kazi kuhamia gitlab.com hadi kwa miundombinu inayotegemea Kubernetes.

Mhariri NB: Ikiwa tayari umesikia kuhusu teknolojia ya Kubernetes (na sina shaka kuwa unayo), lakini bado haujaigusa kwa mikono yako, napendekeza ushiriki katika kozi za mtandaoni. Msingi wa Kubernetes, ambayo itafanyika Septemba 28-30, na Kubernetes Mega, ambayo itafanyika Oktoba 14-16. Hii itawawezesha kusafiri kwa ujasiri na kufanya kazi na teknolojia.

Hizi ni njia mbili ambazo hufuata lengo moja: uwasilishaji wa haraka wa masasisho, kwa gitlab.com na kwa wateja kwenye vituo vyao.

Mawazo yoyote au mapendekezo kwa ajili yetu?

Kila mtu anakaribishwa kuchangia GitLab, na tunakaribisha maoni kutoka kwa wasomaji wetu. Ikiwa una mawazo yoyote kwa timu yetu ya uwasilishaji, usisite tengeneza ombi na taarifa team: Delivery.

Chanzo: mapenzi.com

Kuongeza maoni