Ikastaroko ikasleentzat prestatutako artikuluaren itzulpena "DevOps praktikak eta tresnak" OTUS hezkuntza proiektuan.

Monobiltegi bat aukeratu beharko zenuke zure taldeetan sustatzen duen jokabidea gardentasuna eta erantzukizun partekatua delako, batez ere taldeak hazten diren heinean. Edozein modutan, tresnetan inbertitu beharko duzu, baina beti da hobe portaera lehenetsia zure komandoetan nahi duzun portaera bada.

Zergatik ari gara honetaz hitz egiten?

Matt Kleinek idatzi zuen artikulua "Monorepos: Mesedez, ez!"  (itzultzailearen oharra: Habré-ri buruzko itzulpena "Monorepositorioak: mesedez ez"). Matt gustatzen zait, oso argia dela uste dut eta bere ikuspuntua irakurri beharko zenuke. Hasiera batean Twitter-en argitaratu zuen inkesta:

itzulpena:
Urteberri egun honetan, monogordetegiak zein barregarriak diren eztabaidatuko dut. 2019 lasai hasi zen. Horren harira, inkesta bat eskaintzen dizut. Zeintzuk dira fanatiko handiak? Laguntzaileak:
- Monorepo
- Herdoilaren
- Inkesta okerra / biak

Nire erantzuna izan zen: "Literalki bi pertsona horiek naiz". Rust droga bat nola den hitz egin beharrean, ikus dezagun zergatik oker dagoen uste dut monogordetegietan. Zure buruari buruz pixka bat. Chef Softwareko zuzendaria naiz. 100 ingeniari inguru ditugu, 11-12 urte inguruko kode oinarri bat eta 4 produktu nagusi ditugu. Kode hauetako batzuk polirepositorio batean daude (nire hasierako posizioan), beste batzuk monobiltegi batean daude (nire uneko posizioan).

Hasi baino lehen: hemen egiten dudan argudio guztiak bi biltegi motetan aplikatuko dira. Nire ustez, ez dago arrazoi teknikorik biltegi mota bat beste bat baino gehiago aukeratzeko. Edozein hurbilketa funtziona dezakezu. Pozik hitz egiten dut horretaz, baina ez zaizkit interesatzen bata bestearen gainetik dagoen arrazoi tekniko artifizialak.

Bat nator Matten puntuaren lehen zatiarekin:

Zeren eskalan, monobiltegi batek konpontzen dituen arazo berdinak konponduko ditu, baina, aldi berean, zure kodea ondo lotzera behartzen zaitu eta zure bertsio kontrolatzeko sistemaren eskalagarritasuna areagotzeko ahalegin izugarriak eskatuko ditu.

Arazo berberak konpondu beharko dituzu monobiltegi bat edo poligordetegi bat aukeratzen duzun kontuan hartu gabe. Nola kaleratzen dituzu kaleratzeak? Zein da zure ikuspegia eguneratzeak? Atzerako bateragarritasuna? Proiektuen menpekotasun gurutzatuak? Zein arkitektura-estilo dira onargarriak? Nola kudeatzen duzu eraikitzeko eta probatzeko azpiegiturak? Zerrenda amaigabea da. Eta hazi ahala konponduko dituzu guztiak. Ez dago doako gaztarik.

Matten argudioa errespetatzen ditudan ingeniari (eta kudeatzaile) askok partekatutako ikuspegien antzekoa dela uste dut. Hau osagaian lan egiten duen ingeniariaren edo osagaian lan egiten duen taldearen ikuspegitik gertatzen da. Horrelako gauzak entzuten dituzu:

• Kode-oinarria handia da - ez dut zabor guzti hau behar.
• Proba egitea zailagoa da, behar ez dudan zabor hori guztia probatu behar baitut.
• Zailagoa da kanpoko menpekotasunekin lan egitea.
• Nire bertsio birtualak kontrolatzeko sistemak behar ditut.

Jakina, puntu hauek guztiak justifikatuta daude. Bi kasuetan gertatzen da hori -poligordetegian nire zaborra daukat, eraikitzeko behar denaz gain... Baliteke beste zabor batzuk ere behar izatea. Beraz, "besterik gabe" proiektu osoa egiaztatzen duten tresnak sortzen ditut. Edo monobiltegi faltsu bat sortzen dut azpimoduluekin. Egun osoan zehar ibili gintezke honetaz. Baina uste dut Matt-en argudioak arrazoi nagusia falta duela, eta hori nahiko irauli nuen monobiltegiaren alde:

Komunikazioa sortzen du eta arazoak erakusten ditu

Biltegiak bereizten ditugunean, de facto koordinazio eta gardentasun arazo bat sortzen dugu. Hau taldeei buruz dugun pentsamoldeari dagokio (batez ere kide indibidualei buruz hauetaz pentsatzeko moduari): osagai jakin baten erantzuleak gara. Isolamendu erlatiboan lan egiten dugu. Mugak nire taldean eta lantzen ari garen osagaian finkatzen dira.

Arkitektura konplexuagoa bihurtzen den heinean, talde batek ezin du jada bakarrik kudeatu. Oso ingeniari gutxik dute sistema osoa buruan. Demagun B, C eta D taldeek erabiltzen duten A osagai partekatu bat kudeatzen duzula. A taldea birfactoring, APIa hobetzen eta barne inplementazioa ere aldatzen ari da. Ondorioz, aldaketak ez dira atzerantz bateragarriak. Zer aholku duzu?

• Bilatu API zaharra erabiltzen den toki guztiak.
• Ba al dago API berria erabili ezin den tokirik?
• Beste osagai batzuk konpondu eta probatu ditzakezu apurtzen ez direla ziurtatzeko?
• Probatu al ditzakete talde hauek zure aldaketak oraintxe bertan?

Kontuan izan galdera hauek biltegi motatik independenteak direla. B, C eta D taldeak aurkitu beharko dituzu. Haiekin hitz egin beharko duzu, ordua ezagutu, lehentasunak ulertu. Espero dugu behintzat.

Inork ez du benetan hau egin nahi. Hau API madarikatua konpontzea baino dibertigarri gutxiago da. Guztia gizatiarra eta nahasia da. Poligordetegi batean, aldaketak egin ditzakezu, osagai horretan lan egiten duten pertsonei eman (ziurrenik ez B, C edo D) berrikusteko eta aurrera egin. B, C eta D taldeek oraingo bertsioarekin gera daitezke oraingoz. Zure jenioa konturatzen direnean berrituko dira!

Monobiltegi batean, erantzukizuna lehenespenez aldatzen da. A taldeak bere osagaia aldatzen du eta, kontuz ibili ezean, B, C eta D berehala hausten ditu. Honek B, C eta D A-ren atean agertzea dakar, A taldeak muntaia zergatik hautsi duen galdetuz. Horrek irakasten dio Ari ezin dutela nire goiko zerrenda saltatu. Egingo dutenari buruz hitz egin behar dute. B, C eta D mugi daitezke? Zer gertatzen da B eta C-k ahal izango balute, baina D algoritmo zaharraren portaeraren albo-ondorio batekin estuki erlazionatuta egongo balitz?

Ondoren, egoera honetatik nola aterako garen hitz egin behar dugu:

1. Barne API anitzentzako onartzen da, eta algoritmo zaharra zaharkituta bezala markatuko du D-k erabiltzeari utzi arte.
2. Hainbat bertsiotarako laguntza, bat interfaze zaharrarekin, bestea berriarekin.
3. Atzeratu A-ren aldaketak kaleratzea B, C eta D aldi berean onartu arte.

Demagun 1, hainbat API hautatu ditugula. Kasu honetan bi kode ditugu. Zaharrak eta berriak. Nahiko erosoa egoera batzuetan. Kode zaharra berriro egiaztatzen dugu, zaharkituta bezala markatzen dugu eta kentzeko egutegia adosten dugu D taldearekin. Funtsean, berdin-berdina da poli eta mono biltegietarako.

Hainbat bertsio kaleratzeko, adar bat behar dugu. Orain bi osagai ditugu - A1 eta A2. B eta C taldeek A2 erabiltzen dute eta D A1 erabiltzen dute. Osagai guztiak kaleratzeko prest egon behar dugu, D-k aurrera egin baino lehen segurtasun-eguneratzeak eta bestelako akatsen konponketak behar izan daitezkeelako. Poligordetegi batean, ondo sentitzen den adar luze batean ezkutatu dezakegu. Monobiltegi batean, kodea modulu berri batean sortzera behartzen dugu. D taldeak oraindik aldaketak egin beharko ditu osagai "zaharrean". Guztiek ikus dezakete hemen ordaintzen ari garen kostua - orain kode bikoitza dugu, eta A1 eta A2-i aplikatzen zaizkien akatsen konponketak biei aplikatu behar zaizkie. Poligordetegi batean adarkatze ikuspegiarekin, hau gerezi-hautaketaren atzean ezkutatzen da. Kostua baxuagoa dela uste dugu bikoiztasunik ez dagoelako. Ikuspuntu praktikotik, kostua berdina da: bi kode-oinarri berdin-berdinak eraiki, askatu eta mantenduko dituzu haietako bat ezabatu arte. Desberdintasuna da monogordetegi batekin min hori zuzena eta ikusgaia dela. Hau are okerragoa da, eta hori ona da.

Azkenik, hirugarren puntura iritsi gara. Askatzeko atzerapena. Baliteke A-k egindako aldaketek A taldearen bizitza hobetzea. Garrantzitsua, baina ez premiazkoa. Atzeratu al dezakegu? Poligordetegi batean, hau bultzatzen dugu artefaktua ainguratzeko. D taldeari hau esaten diogu, noski. Jarrai ezazu bertsio zaharrean, lortu arte! Honek koldar jokatzeko prestatzen zaitu. A taldeak bere osagaian lanean jarraitzen du, D taldea gero eta bertsio zaharkituagoa erabiltzen ari dela alde batera utzita (hori da D taldearen arazoa, ergelak dira). Bien bitartean, D taldeak gaizki hitz egiten du A taldeak kode-egonkortasunari buruz duen jarrera arduragabeaz, horretaz hitz egiten badute. Hilabeteak pasatzen dira. Azkenik, D taldeak eguneratzeko aukera aztertzea erabakitzen du, baina A-k aldaketa gehiago baino ez ditu. A taldeak ia ez du gogoratzen noiz edo nola hautsi zuten D. Berritzea mingarriagoa da eta luzeagoa izango da. Horrek lehentasunezko pilan beherago bidaltzen du. A-n adar bat egitera behartzen gaituen segurtasun arazo bat daukagun egunera arte. A taldeak denboran atzera egin behar du, D egonkor zegoen puntu bat aurkitu, arazoa bertan konpondu eta askatzeko prest jarri. Hau da, de facto, jendeak egiten duen aukera, eta, alde handiz, okerrena da. A eta D taldearentzat ona dela dirudi, elkarri kasurik egin gabe.

Monobiltegi batean, hirugarrena ez da aukera bat. Egoerari bi modutan aurre egitera behartuta zaude. Bi kaleratze adar izatearen kostuak ikusi behar dituzu. Ikasi atzerako bateragarritasuna hausten duten eguneratzeetatik babesten. Baina garrantzitsuena: ezin duzu saihestu elkarrizketa zail bat izatea.

Nire esperientziaren arabera, taldeak handitzen direnean, jada ez da posible sistema osoa kontuan edukitzea, eta hori da garrantzitsuena. Discord-aren ikusgarritasuna hobetu behar duzu sisteman. Aktiboki lan egin behar duzu taldeek beren osagaietatik aldendu eta beste talde eta kontsumitzaileen lana aztertzeko.

Bai, polirepositorioaren arazoa konpontzen saiatzen diren tresnak sor ditzakezu. Baina enpresa handietan etengabeko entrega eta automatizazioa irakasten dudan esperientziak hau esaten dit: tresna gehigarririk erabili gabe portaera lehenetsia ikustea espero duzun portaera da. Polirepositorio baten portaera lehenetsia isolamendua da, hori da kontua. Monobiltegi baten portaera lehenetsia erantzukizun partekatua eta gardentasuna da, hori da kontua. Bi kasuetan, ertzak leunduko dituen tresna bat sortuko dut. Lider gisa, monobiltegi bat aukeratuko dut aldiro, tresnek nahi dudan kultura indartu behar dutelako, eta kultura erabaki txikietatik eta taldearen eguneroko lanetik datorrelako.

Erregistratutako erabiltzaileek soilik parte hartu dezakete inkestan. Hasi saioa, mesedez.

Zeintzuk dira fanatikorik handienak? Laguntzaileak:

• Monorepo

• Herdoilaren

• Inkesta okerra / biak

33 erabiltzailek eman dute botoa. 13 erabiltzaile abstenitu ziren.

Iturria: www.habr.com