Tafsiri ya makala iliyotayarishwa kwa wanafunzi wa kozi "Mazoea na zana za DevOps" katika mradi wa elimu wa OTUS.

Unapaswa kuchagua hazina moja kwa sababu tabia inayokuza katika timu zako ni ya uwazi na uwajibikaji wa pamoja, haswa kadri timu zinavyokua. Vyovyote vile, itabidi uwekeze kwenye zana, lakini ni bora kila wakati ikiwa tabia chaguo-msingi ni tabia unayotaka katika amri zako.

Kwa nini tunazungumzia hili?

Matt Klein aliandika makala hiyo "Monorepos: Tafadhali usifanye!"  (maelezo ya mtafsiri: tafsiri kwenye Habré "Hazina moja: tafadhali usifanye") Nampenda Matt, nadhani ana akili sana na unapaswa kusoma maoni yake. Hapo awali alichapisha kura hiyo kwenye Twitter:

Tafsiri:
Siku hii ya Mwaka Mpya, nitabishana juu ya jinsi hazina za ujinga zilivyo. 2019 ilianza kimya kimya. Kwa mtazamo huu, ninakupa uchunguzi. Washabiki wakubwa ni akina nani? Wafuasi:
- Monorepo
- Kutu
- Kura ya maoni si sahihi / zote mbili

Jibu langu lilikuwa, "Mimi ni watu wote wawili." Badala ya kuzungumza juu ya jinsi Rust ni dawa, hebu tuangalie kwa nini nadhani ana makosa kuhusu hifadhi za monorepositories. Kidogo kuhusu wewe mwenyewe. Mimi ndiye CTO wa Programu ya Chef. Tuna wahandisi wapatao 100, msingi wa msimbo unaorudi nyuma kama miaka 11-12, na bidhaa 4 kuu. Baadhi ya nambari hizi ziko kwenye hifadhidata (nafasi yangu ya kuanzia), zingine ziko kwenye hazina moja (nafasi yangu ya sasa).

Kabla sijaanza: kila hoja ninayotoa hapa itatumika kwa aina zote mbili za hazina. Kwa maoni yangu, hakuna sababu ya kiufundi kwa nini unapaswa kuchagua aina moja ya hazina juu ya nyingine. Unaweza kufanya mbinu yoyote ifanye kazi. Nina furaha kulizungumzia, lakini sivutiwi na sababu za kiufundi za bandia kwa nini mtu ni bora kuliko mwingine.

Nakubaliana na sehemu ya kwanza ya hoja ya Matt:

Kwa sababu kwa kiwango, hazina moja itasuluhisha shida zote ambazo hazina poli hutatua, lakini wakati huo huo ikikulazimisha kuunganisha msimbo wako kwa nguvu na kuhitaji juhudi za ajabu ili kuongeza kiwango cha mfumo wako wa kudhibiti toleo.

Utalazimika kusuluhisha shida sawa bila kujali unachagua hazina moja au polyrepository. Unatoaje matoleo? Je, una mtazamo gani kuhusu masasisho? Utangamano wa nyuma? Utegemezi wa mradi tofauti? Ni mitindo gani ya usanifu inayokubalika? Je, unasimamiaje muundo wako wa kujenga na kujaribu? Orodha haina mwisho. Na utazitatua zote unapokua. Hakuna jibini la bure.

Nadhani hoja ya Matt ni sawa na maoni yaliyoshirikiwa na wahandisi wengi (na wasimamizi) ninaowaheshimu. Hii hutokea kutokana na mtazamo wa mhandisi anayefanya kazi kwenye kipengele au timu inayofanya kazi kwenye kipengele. Unasikia mambo kama:

• Codebase ni kubwa - sihitaji takataka hii yote.
• Ni ngumu zaidi kujaribu kwa sababu lazima nijaribu takataka hii yote ambayo siitaji.
• Ni ngumu zaidi kufanya kazi na utegemezi wa nje.
• Nahitaji mifumo yangu mwenyewe ya udhibiti wa toleo la mtandaoni.

Bila shaka, pointi hizi zote ni haki. Hii hutokea katika matukio yote mawili - katika polyrepository nina takataka yangu mwenyewe, pamoja na ile inayohitajika kwa ajili ya kujenga ... Ninaweza pia kuhitaji takataka nyingine. Kwa hivyo mimi "kwa urahisi" huunda zana zinazoangalia mradi mzima. Au ninaunda hazina bandia na submodules. Tunaweza kutembea kuzunguka hii siku nzima. Lakini nadhani hoja ya Matt inakosa sababu kuu, ambayo niliipindua sana kwa niaba ya hazina moja:

Inachochea mawasiliano na inaonyesha matatizo

Tunapotenganisha hazina, tunatengeneza tatizo la uratibu na uwazi. Hii inalingana na jinsi tunavyofikiri kuhusu timu (hasa jinsi washiriki binafsi wanavyofikiri kuzihusu): tunawajibika kwa kipengele fulani. Tunafanya kazi kwa kutengwa kwa jamaa. Mipaka imewekwa kwenye timu yangu na sehemu tunayoshughulikia.

Kadiri usanifu unavyozidi kuwa mgumu zaidi, timu moja haiwezi tena kuisimamia peke yake. Wahandisi wachache sana wana mfumo mzima kichwani mwao. Hebu tuseme unadhibiti kipengele A kilichoshirikiwa ambacho kinatumiwa na Timu B, C, na D. Timu A inarekebisha upya, inaboresha API, na pia inabadilisha utekelezaji wa ndani. Kwa hivyo, mabadiliko hayaendani nyuma. Una ushauri gani?

• Pata maeneo yote ambapo API ya zamani inatumika.
• Je, kuna mahali ambapo API mpya haiwezi kutumika?
• Je, unaweza kurekebisha na kujaribu vipengele vingine ili kuhakikisha havivunji?
• Je, timu hizi zinaweza kujaribu mabadiliko yako sasa hivi?

Tafadhali kumbuka kuwa maswali haya hayategemei aina ya hazina. Utahitaji kupata timu B, C na D. Utahitaji kuzungumza nao, kujua muda, kuelewa vipaumbele vyao. Angalau tunatarajia utafanya.

Hakuna mtu anayetaka kufanya hivi. Hii haifurahishi sana kuliko kurekebisha tu API mbaya. Yote ni ya kibinadamu na ya fujo. Katika hifadhi ya poli, unaweza tu kufanya mabadiliko, kuwapa watu wanaofanya kazi kwenye sehemu hiyo (labda si B, C au D) kwa ukaguzi, na kuendelea. Timu B, C na D zinaweza kubaki na toleo lao la sasa kwa sasa. Watafanywa upya watakapotambua fikra zako!

Katika hifadhi moja, jukumu huhamishwa kwa chaguo-msingi. Timu A hubadilisha kijenzi chake na, ikiwa si makini, huvunja B, C na D mara moja. Hii husababisha B, C na D kujitokeza kwenye mlango wa A, na kushangaa kwa nini Timu A ilivunja mkusanyiko. Hii inafundisha A kwamba hawawezi kuruka orodha yangu hapo juu. Ni lazima wazungumze juu ya kile watakachofanya. B, C na D zinaweza kusonga? Ikiwa B na C wanaweza, lakini D ilihusiana kwa karibu na athari ya tabia ya zamani ya algorithm?

Kisha tunapaswa kuzungumza juu ya jinsi tutakavyotoka katika hali hii:

1. Usaidizi kwa API nyingi za ndani, na itatia alama kwenye algoriti ya zamani kama iliyoacha kutumika hadi D itakapoacha kuitumia.
2. Usaidizi wa matoleo mengi ya matoleo, moja yenye kiolesura cha zamani, kimoja na kipya.
3. Kuchelewesha kutolewa kwa mabadiliko ya A hadi B, C, na D waweze kuyakubali kwa wakati mmoja.

Wacha tuseme tumechagua 1, API kadhaa. Katika kesi hii tuna vipande viwili vya kanuni. Zamani na mpya. Inafaa kabisa katika hali zingine. Tunaangalia tena msimbo wa zamani, utie alama kuwa umeacha kutumika, na kukubaliana na ratiba ya kuondoa na timu ya D inayofanana Kimsingi kwa hazina nyingi na mono.

Ili kutoa matoleo mengi, tunahitaji tawi. Sasa tuna vipengele viwili - A1 na A2. Timu B na C hutumia A2 na D hutumia A1. Tunahitaji kila kipengee kiwe tayari kwa kutolewa kwa sababu masasisho ya usalama na marekebisho mengine ya hitilafu yanaweza kuhitajika kabla D haijasonga mbele. Katika polyrepository, tunaweza kuficha hii katika tawi la muda mrefu ambalo linahisi vizuri. Katika hifadhi moja, tunalazimisha msimbo kuundwa katika moduli mpya. Timu D bado italazimika kufanya mabadiliko kwenye sehemu ya "zamani". Kila mtu anaweza kuona gharama tunayolipa hapa - sasa tuna nambari ya kuthibitisha mara mbili zaidi, na marekebisho yoyote ya hitilafu ambayo yanatumika kwa A1 na A2 lazima yatumike kwa zote mbili. Kwa mbinu ya matawi katika hifadhi ya polyrepository, hii imefichwa nyuma ya cherry-pick. Tunachukulia gharama kuwa ya chini kwa sababu hakuna kurudia. Kwa mtazamo wa vitendo, gharama ni sawa: utaunda, kutolewa, na kudumisha misingi miwili inayofanana kwa kiasi kikubwa hadi uweze kufuta mojawapo. Tofauti ni kwamba kwa monorepository maumivu haya ni ya moja kwa moja na yanaonekana. Hii ni mbaya zaidi, na hiyo ni nzuri.

Hatimaye, tulifikia hatua ya tatu. Kucheleweshwa kwa kutolewa. Inawezekana kwamba mabadiliko yaliyofanywa na A yataboresha maisha ya Timu A. Muhimu, lakini si ya dharura. Je, tunaweza kuchelewa tu? Katika hifadhi ya poli, tunasukuma hii ili kubandika kisanii. Bila shaka tunaiambia Timu D hili. Baki kwenye toleo la zamani hadi upate maelezo zaidi! Hii inakuweka juu ya kucheza mwoga. Timu A inaendelea kufanyia kazi kijenzi chake, ikipuuza ukweli kwamba Timu D inatumia toleo linalozidi kupitwa na wakati (hilo ni tatizo la Timu D, wao ni wajinga). Wakati huo huo, Timu D inazungumza vibaya kuhusu mtazamo wa kutojali wa Timu A kuelekea uthabiti wa kanuni, ikiwa wanaizungumzia hata kidogo. Miezi inapita. Hatimaye, Timu D inaamua kuangalia uwezekano wa sasisho, lakini A pekee ina mabadiliko zaidi. Timu A haikumbuki lini au jinsi walivunja D. Uboreshaji ni chungu zaidi na utachukua muda mrefu zaidi. Ambayo huituma chini zaidi safu ya kipaumbele. Mpaka siku tuna suala la usalama katika A ambalo linatulazimisha kutengeneza tawi. Timu A lazima irudi nyuma, itafute hatua wakati D ilikuwa thabiti, irekebishe tatizo hapo, na iwe tayari kwa kutolewa. Huu ndio chaguo la ukweli ambalo watu hufanya, na ni mbaya zaidi. Inaonekana kuwa nzuri kwa Timu A na Timu D mradi tu tunaweza kupuuza kila mmoja.

Katika hazina moja, ya tatu sio chaguo. Unalazimika kukabiliana na hali hiyo kwa njia moja kati ya mbili. Unahitaji kuona gharama za kuwa na matawi mawili ya kutolewa. Jifunze kujilinda dhidi ya masasisho ambayo yanavunja uoanifu wa nyuma. Lakini muhimu zaidi: huwezi kuepuka kuwa na mazungumzo magumu.

Kwa uzoefu wangu, timu zinapokuwa kubwa, haiwezekani tena kuweka mfumo mzima akilini, na hiyo ndiyo sehemu muhimu zaidi. Lazima uboresha mwonekano wa mifarakano katika mfumo. Lazima ufanye kazi kwa bidii ili kupata timu kutazama mbali na vifaa vyao na kutazama kazi ya timu zingine na watumiaji.

Ndiyo, unaweza kuunda zana zinazojaribu kutatua tatizo la polyrepository. Lakini uzoefu wangu wa kufundisha uwasilishaji endelevu na otomatiki katika biashara kubwa huniambia hivi: tabia chaguo-msingi bila matumizi ya zana za ziada ni tabia unayotarajia kuona. Tabia chaguo-msingi ya hifadhi ya poli ni kutengwa, hiyo ndiyo hoja nzima. Tabia chaguo-msingi ya hazina moja ni uwajibikaji wa pamoja na uwazi, hiyo ndiyo hoja nzima. Katika visa vyote viwili, nitaunda zana ambayo itapunguza kingo mbaya. Kama kiongozi, nitachagua hazina kila wakati kwa sababu zana zinahitaji kuimarisha utamaduni ninaotaka, na utamaduni unatokana na maamuzi madogo na kazi ya kila siku ya timu.

Watumiaji waliojiandikisha pekee ndio wanaweza kushiriki katika utafiti. Weka sahihitafadhali.

Washabiki wakubwa ni akina nani? Wafuasi:

• Monorepo

• Kutu

• Kura ya maoni si sahihi / zote mbili

Watumiaji 33 walipiga kura. Watumiaji 13 walijizuia.

Chanzo: mapenzi.com