Paano kami naglalabas ng mga patch ng software sa GitLab

Sa GitLab, pinoproseso namin ang mga pag-aayos ng software sa dalawang paraan: manu-mano at awtomatiko. Magbasa para matutunan ang tungkol sa trabaho ng release manager sa paggawa at paghahatid ng mahahalagang update sa pamamagitan ng automated na pag-deploy sa gitlab.com, pati na rin ang mga patch para sa mga user na makatrabaho sa kanilang sariling mga installation.

Inirerekomenda kong magtakda ng paalala sa iyong smartwatch: bawat buwan sa ika-22, ang mga user na nagtatrabaho sa GitLab sa kanilang mga pasilidad ay makakakita ng mga update sa kasalukuyang bersyon ng aming produkto. Ang buwanang pagpapalabas ay naglalaman ng mga bagong feature, mga pagpapaunlad ng mga umiiral na, at kadalasang nagpapakita ng resulta ng mga kahilingan ng komunidad para sa tooling o mga pagsasanib.

Ngunit, tulad ng ipinapakita ng kasanayan, ang pagbuo ng software ay bihirang walang mga bahid. Kapag may natuklasang bug o kahinaan sa seguridad, gagawa ang tagapamahala ng release sa pangkat ng paghahatid ng patch para sa aming mga user kasama ang kanilang mga pag-install. Ang Gitlab.com ay ina-update sa panahon ng proseso ng CD. Tinatawag namin itong proseso ng CD na awtomatikong pag-deploy upang maiwasan ang pagkalito sa feature ng CD sa GitLab. Maaaring isama ng prosesong ito ang mga suhestiyon mula sa mga pull request na isinumite ng mga user, customer, at ng aming internal development team, upang ang paglutas sa nakakainip na problema sa pag-release ng mga patch ay malulutas sa dalawang magkaibang paraan.

«Tinitiyak namin na lahat ng ginagawa ng mga developer ay naka-deploy sa lahat ng kapaligiran araw-araw bago ito ilunsad sa GitLab.com", paliwanag Marin Jankovki, Senior Technical Manager, Infrastructure Department. "Isipin ang mga release para sa iyong mga pag-install bilang mga snapshot para sa mga deployment ng gitlab.com, kung saan nagdagdag kami ng hiwalay na mga hakbang upang lumikha ng isang package upang magamit ito ng aming mga user sa pag-install sa kanilang mga pag-install'.

Anuman ang bug o kahinaan, ang mga customer ng gitlab.com ay makakatanggap ng mga pag-aayos sa ilang sandali pagkatapos na mai-publish ang mga ito, na isang benepisyo ng automated na proseso ng CD. Ang mga patch para sa mga user na may sarili nilang mga pag-install ay nangangailangan ng hiwalay na paghahanda ng release manager.

Nagsusumikap ang delivery team na i-automate ang karamihan sa mga prosesong kasangkot sa paggawa ng mga release para mabawasan MTTP (mean time to production, ibig sabihin, oras na ginugol sa produksyon), ang tagal ng panahon mula sa pagproseso ng kahilingan sa pagsasama ng developer hanggang sa pag-deploy sa gitlab.com.

«Ang layunin ng pangkat ng paghahatid ay tiyaking makakagalaw tayo nang mas mabilis bilang isang kumpanya, o hindi bababa sa gawing mas mabilis ang mga tao sa paghahatid, tama?, sabi ni Marin.

Parehong nakikinabang ang mga customer ng gitlab.com at mga user ng kanilang mga pag-install mula sa mga pagsusumikap ng pangkat ng paghahatid na bawasan ang mga oras ng pag-ikot at pabilisin ang mga deployment. Sa artikulong ito ay ipapaliwanag natin ang pagkakatulad at pagkakaiba sa pagitan ng dalawang pamamaraang ito. mga isyu, at ilalarawan din namin kung paano naghahanda ang aming team ng paghahatid ng mga patch para sa mga user na nagtatrabaho sa kanilang mga pasilidad, pati na rin kung paano namin tinitiyak na ang gitlab.com ay napapanahon gamit ang automated na pag-deploy.

Ano ang ginagawa ng isang release manager?

Mga miyembro ng koponan buwan-buwan ilipat ang tungkulin ng release manager ang aming mga release sa mga user sa kanilang mga pasilidad, kabilang ang mga patch at security release na maaaring mangyari sa pagitan ng mga release. Sila rin ang may pananagutan sa pangunguna sa paglipat ng kumpanya sa awtomatiko, tuluy-tuloy na pag-deploy.

Gumagamit ang mga self-installation release at gitlab.com release ng magkatulad na workflow ngunit tumatakbo sa magkaibang oras, paliwanag ni Marin.

Una at pangunahin, tinitiyak ng release manager, anuman ang uri ng release, na ang GitLab ay available at secure mula sa sandaling inilunsad ang application sa gitlab.com, kabilang ang pagtiyak na ang parehong mga isyu ay hindi napupunta sa imprastraktura ng mga customer sa kanilang sariling mga kapasidad.

Kapag ang isang bug o kahinaan ay namarkahang maayos sa GitLab, dapat suriin ng tagapamahala ng release na ito ay isasama sa mga patch o mga update sa seguridad para sa mga user na may kanilang mga pag-install. Kung siya ay nagpasya na ang isang bug o kahinaan ay karapat-dapat sa isang update, ang paghahanda sa trabaho ay magsisimula.

Ang tagapamahala ng paglabas ay dapat magpasya kung maghahanda ng isang pag-aayos, o kung kailan ito ipapatupad - at ito ay lubos na nakadepende sa konteksto ng sitwasyon, "samantala, ang mga makina ay hindi kasinghusay sa pamamahala ng konteksto gaya ng mga tao"sabi ni Marin.

Ito ay tungkol sa mga pag-aayos

Ano ang mga patch at bakit natin ito kailangan?

Ang tagapamahala ng paglabas ay magpapasya kung maglalabas ng isang pag-aayos batay sa kalubhaan ng bug.

Ang mga error ay nag-iiba depende sa kanilang kalubhaan. Kaya't ang mga error sa S4 o S3 ay maaaring istilo, tulad ng pag-aalis ng pixel o icon. Ito ay hindi gaanong mahalaga, ngunit walang makabuluhang epekto sa daloy ng trabaho ng sinuman, na nangangahulugan na ang posibilidad na ang isang pag-aayos ay malilikha para sa mga naturang error sa S3 o S4, paliwanag ni Marin.

Gayunpaman, ang mga kahinaan sa S1 o S2 ay nangangahulugan na ang user ay hindi dapat mag-update sa pinakabagong bersyon, o may malaking bug na nakakaapekto sa workflow ng user. Kung kasama ang mga ito sa tracker, maraming user ang nakatagpo sa kanila, kaya agad na magsisimula ang release manager sa paghahanda ng pag-aayos.

Kapag handa na ang isang patch para sa mga kahinaan na S1 o S2, sisimulan ng release manager na i-release ang patch.

Halimbawa, ginawa ang GitLab 12.10.1 patch pagkatapos matukoy ang ilang isyu sa pag-block at inayos ng mga developer ang pinagbabatayan na isyu na nagdudulot sa kanila. Sinuri ng Tagapamahala ng Paglabas ang kawastuhan ng mga itinalagang antas ng kalubhaan, at pagkatapos ng kumpirmasyon, inilunsad ang proseso ng pagpapalabas ng pag-aayos, na handa sa loob ng XNUMX na oras pagkatapos matuklasan ang mga problema sa pagharang.

Kapag maraming S4, S3 at S2 ang naipon, tinitingnan ng tagapamahala ng release ang konteksto upang matukoy ang pagkaapurahan ng pagpapalabas ng pag-aayos, at kapag naabot ang isang tiyak na bilang ng mga ito, pinagsama-sama at inilabas ang lahat. Ang mga pag-aayos pagkatapos ng pagpapalabas o mga update sa seguridad ay ibinubuod sa mga post sa blog.

Paano gumagawa ng mga patch ang isang release manager

Gumagamit kami ng GitLab CI at iba pang feature tulad ng aming ChatOps para bumuo ng mga patch. Sisimulan ng tagapamahala ng release ang paglabas ng pag-aayos sa pamamagitan ng pag-activate sa koponan ng ChatOps sa aming panloob na channel #releases sa Slack.

/chatops run release prepare 12.10.1

Gumagana ang ChatOps sa loob ng Slack upang mag-trigger ng iba't ibang mga kaganapan, na pagkatapos ay pinoproseso at isasagawa ng GitLab. Halimbawa, nag-set up ang delivery team ng ChatOps para i-automate ang iba't ibang bagay para maglabas ng mga patch.

Kapag sinimulan na ng release manager ang ChatOps team sa Slack, ang iba pang gawain ay awtomatikong mangyayari sa GitLab gamit ang CICD. Mayroong two-way na komunikasyon sa pagitan ng ChatOps sa Slack at GitLab sa panahon ng proseso ng paglabas habang ina-activate ng release manager ang ilan sa mga pangunahing hakbang sa proseso.

Ang video sa ibaba ay nagpapakita ng teknikal na proseso ng paghahanda ng isang patch para sa GitLab.

Paano gumagana ang awtomatikong pag-deploy sa gitlab.com

Ang proseso at mga tool na ginamit upang i-update ang gitlab.com ay katulad ng mga ginamit upang lumikha ng mga patch. Ang pag-update sa gitlab.com ay nangangailangan ng mas kaunting manu-manong trabaho mula sa punto ng view ng release manager.

Sa halip na magpatakbo ng mga deployment gamit ang ChatOps, gumagamit kami ng mga feature ng CI hal. naka-iskedyul na mga pipeline, kung saan maaaring mag-iskedyul ang tagapamahala ng release ng ilang partikular na pagkilos na isasagawa sa kinakailangang oras. Sa halip na manu-manong proseso, mayroong pipeline na pana-panahong tumatakbo nang isang beses sa isang oras na nagda-download ng mga bagong pagbabagong ginawa sa mga proyekto ng GitLab, nag-i-package sa mga ito at nag-iskedyul ng pag-deploy, at awtomatikong nagpapatakbo ng pagsubok, QA at iba pang kinakailangang hakbang.

“Kaya marami kaming deployment na tumatakbo sa iba't ibang environment bago ang gitlab.com, at pagkatapos na maayos ang kalagayan ng mga environment na iyon at nagpapakita ng magagandang resulta ang pagsubok, sisimulan ng release manager ang mga aksyon sa pag-deploy ng gitlab.com," sabi ni Marin.

Ang teknolohiya ng CICD para sa pagsuporta sa mga update ng gitlab.com ay nag-o-automate sa buong proseso hanggang sa punto kung saan ang tagapamahala ng release ay dapat na manu-manong ilunsad ang pag-deploy ng kapaligiran ng produksyon sa gitlab.com.

Detalyado si Marin tungkol sa proseso ng pag-update ng gitlab.com sa video sa ibaba.

Ano pa ang ginagawa ng delivery team?

Ang pangunahing pagkakaiba sa pagitan ng mga proseso ng pag-update ng gitlab.com at pag-release ng mga patch sa mga customer na nasa bahay ay ang huling proseso ay nangangailangan ng mas maraming oras at mas manu-manong trabaho mula sa release manager.

"Minsan ay inaantala namin ang paglalabas ng mga patch sa mga customer gamit ang kanilang mga pag-install dahil sa mga naiulat na isyu, mga isyu sa tooling, at dahil maraming mga nuances na kailangang isaalang-alang kapag naglalabas ng isang patch," sabi ni Marin.

Ang isa sa mga panandaliang layunin ng pangkat ng paghahatid ay upang bawasan ang dami ng manu-manong gawain sa bahagi ng tagapamahala ng paglabas upang mapabilis ang pagpapalabas. Nagsusumikap ang team na pasimplehin, i-streamline, at i-automate ang proseso ng paglabas, na makakatulong sa pag-aayos sa mga isyu sa mababang kalubhaan (S3 at S4, tinatayang tagasalin). Ang pagtutok sa bilis ay isang pangunahing tagapagpahiwatig ng pagganap: kinakailangang bawasan ang MTTP - ang oras mula sa pagtanggap ng kahilingan sa pagsasama hanggang sa pag-deploy ng resulta sa gitlab.com - mula sa kasalukuyang 50 oras hanggang 8 oras.

Nagsusumikap din ang delivery team sa paglipat ng gitlab.com sa isang imprastraktura na nakabatay sa Kubernetes.

NB ng editor: Kung narinig mo na ang tungkol sa teknolohiya ng Kubernetes (at wala akong alinlangan na mayroon ka), ngunit hindi mo pa ito nahawakan ng iyong mga kamay, inirerekumenda kong makilahok sa mga online na masinsinang kurso Kubernetes Base, na magaganap sa Setyembre 28-30, at Kubernetes Mega, na magaganap sa Oktubre 14–16. Ito ay magbibigay-daan sa iyong kumpiyansa na mag-navigate at magtrabaho kasama ang teknolohiya.

Ito ang dalawang diskarte na naghahabol sa parehong layunin: mabilis na paghahatid ng mga update, para sa gitlab.com at para sa mga kliyente sa kanilang mga pasilidad.

Anumang mga ideya o rekomendasyon para sa amin?

Inaanyayahan ang lahat na mag-ambag sa GitLab, at tinatanggap namin ang feedback mula sa aming mga mambabasa. Kung mayroon kang anumang mga ideya para sa aming pangkat ng paghahatid, huwag mag-atubiling lumikha ng isang application may paunawa team: Delivery.

Pinagmulan: www.habr.com