Kurs tələbələri üçün hazırlanmış məqalənin tərcüməsi "DevOps təcrübələri və alətləri" OTUS təhsil layihəsində.

Siz monorepozitoriya seçməlisiniz, çünki onun komandalarınızda təşviq etdiyi davranış şəffaflıq və paylaşılan məsuliyyətdir, xüsusən də komandalar böyüdükcə. İstənilən halda, alətlərə investisiya etməli olacaqsınız, lakin standart davranış əmrlərinizdə istədiyiniz davranışdırsa, həmişə daha yaxşıdır.

Niyə bu barədə danışırıq?

Məqaləni Mett Klein yazıb "Monorepos: Xahiş edirəm etmə!"  (tərcüməçinin qeydi: Habré-də tərcümə "Monorepozitorlar: lütfən etməyin"). Mən Metti bəyənirəm, məncə o, çox ağıllıdır və siz onun nöqteyi-nəzərini oxumalısınız. O, əvvəlcə sorğunu Twitter-də dərc edib:

Tərcümə:
Bu Yeni il günü, monorepozitorların nə qədər gülünc olması barədə mübahisə edəcəyəm. 2019 sakit başladı. Bunun ruhunda sizə bir sorğu təklif edirəm. Böyük fanatiklər kimlərdir? Dəstəkləyənlər:
- Monorepo
- Pas
- Yanlış sorğu / hər ikisi

Cavabım belə oldu: “Mən sözün əsl mənasında o insanların hər ikisiyəm”. Rustun necə bir dərman olması haqqında danışmaq əvəzinə, onun monorepozitoriyalar haqqında niyə səhv etdiyini düşündüyünə baxaq. Özünüz haqqında bir az. Mən Chef Software şirkətinin texniki direktoruyam. Bizim 100-ə yaxın mühəndisimiz, təxminən 11-12 il əvvələ gedən kod bazası və 4 əsas məhsulumuz var. Bu kodun bəziləri polirepozitoriyadadır (mənim başlanğıc mövqeyim), bəziləri monorepozitoriyadadır (indiki mövqeyim).

Başlamazdan əvvəl: burada söylədiyim hər bir arqument hər iki növ depoya şamil olunacaq. Fikrimcə, bir növ anbarı digərinə seçmək üçün heç bir texniki səbəb yoxdur. İstənilən yanaşmanı işə yarada bilərsiniz. Bu barədə danışmaqdan məmnunam, amma birinin digərindən üstün olmasının süni texniki səbəbləri məni maraqlandırmır.

Mən Mattın fikrinin birinci hissəsi ilə razıyam:

Çünki miqyasda monorepozitoriya polirepozitoriyanın həll etdiyi eyni problemləri həll edəcək, eyni zamanda sizi kodunuzu sıx birləşdirməyə məcbur edəcək və versiyaya nəzarət sisteminizin miqyasını artırmaq üçün inanılmaz səylər tələb edəcək.

Siz monorepozitoriya və ya polirepozitoriya seçməyinizdən asılı olmayaraq eyni problemləri həll etməli olacaqsınız. Relizləri necə buraxırsınız? Yeniləmələrə münasibətiniz necədir? Geriyə uyğunluq? Layihədən asılılıqlar? Hansı memarlıq üslubları məqbuldur? Quraşdırma və sınaq infrastrukturunuzu necə idarə edirsiniz? Siyahı sonsuzdur. Və böyüdükcə hamısını həll edəcəksiniz. Pulsuz pendir yoxdur.

Düşünürəm ki, Mattin arqumenti hörmət etdiyim bir çox mühəndisin (və menecerlərin) paylaşdığı fikirlərə bənzəyir. Bu, komponent üzərində işləyən mühəndisin və ya komponent üzərində işləyən komandanın perspektivindən baş verir. Belə şeyləri eşidirsiniz:

• Kod bazası böyükdür - mənə bütün bu lazımsız şeylər lazım deyil.
• Test etmək daha çətindir, çünki ehtiyacım olmayan bütün bu zibilləri sınaqdan keçirməliyəm.
• Xarici asılılıqlarla işləmək daha çətindir.
• Mənə öz virtual versiya nəzarət sistemlərim lazımdır.

Təbii ki, bütün bu məqamlar haqlıdır. Bu, hər iki halda baş verir - polirepozitoriyada mənim tikinti üçün lazım olandan əlavə, öz zibillərim var... Mənə başqa zibillər də lazım ola bilər. Beləliklə, mən "sadəcə" bütün layihəni yoxlayan alətlər yaradıram. Və ya alt modullarla saxta monorepozitoriya yaradıram. Bütün günü bunun ətrafında gəzə bilərdik. Ancaq düşünürəm ki, Mattin arqumenti monorepozitoriyanın lehinə olduqca ağır şəkildə çevirdiyim əsas səbəbi qaçırır:

Ünsiyyəti təhrik edir və problemləri göstərir

Biz repozitoriyaları ayıranda faktiki olaraq koordinasiya və şəffaflıq problemi yaradırıq. Bu, komandalar haqqında düşüncə tərzimizə (xüsusilə fərdi üzvlərin onlar haqqında düşünmə tərzinə) uyğun gəlir: biz müəyyən komponentə görə məsuliyyət daşıyırıq. Biz nisbi təcrid şəraitində işləyirik. Sərhədlər mənim komandamda və üzərində işlədiyimiz komponent(lər)də müəyyən edilib.

Memarlıq mürəkkəbləşdikcə, bir komanda artıq onu təkbaşına idarə edə bilməz. Çox az mühəndisin bütün sistemi beynində var. Tutaq ki, siz B, C və D komandaları tərəfindən istifadə edilən paylaşılan A komponentini idarə edirsiniz. A komandası refaktorinq edir, API-ni təkmilləşdirir və həmçinin daxili tətbiqi dəyişir. Nəticədə dəyişikliklər geriyə uyğun deyil. Nə məsləhətiniz var?

• Köhnə API-nin istifadə olunduğu bütün yerləri tapın.
• Yeni API istifadə edilə bilməyən yerlər varmı?
• Digər komponentlərin qırılmamasına əmin olmaq üçün onları düzəldə və sınaqdan keçirə bilərsinizmi?
• Bu komandalar dəyişikliklərinizi hazırda sınaqdan keçirə bilərmi?

Nəzərə alın ki, bu suallar repozitor tipindən asılı deyil. Siz B, C və D komandalarını tapmalı olacaqsınız. Onlarla danışmalı, vaxtı öyrənməli, prioritetlərini başa düşməlisiniz. Heç olmasa, ümid edirik.

Heç kim həqiqətən bunu etmək istəmir. Bu, lənətə gəlmiş API-ni düzəltməkdən daha az əyləncəlidir. Hamısı insani və qarışıqdır. Polirepozitoriyada siz sadəcə olaraq dəyişikliklər edə, onu həmin komponent üzərində işləyən insanlara (yəqin ki, B, C və ya D deyil) nəzərdən keçirmək üçün verə və davam edə bilərsiniz. B, C və D komandaları hələlik hazırkı versiyalarında qala bilərlər. Dahiliyinizi dərk edəndə yenilənəcəklər!

Bir monorepozitoriyada məsuliyyət standart olaraq dəyişdirilir. A komandası öz komponentini dəyişir və ehtiyatlı olmadıqda dərhal B, C və D-ni sındırır. Bu, B, C və D-nin A-nın qapısında görünməsinə gətirib çıxarır və A Komandasının niyə toplantını pozduğu ilə maraqlanır. Bu, A-ya yuxarıdakı siyahımdan keçə bilməyəcəklərini öyrədir. Onlar nə edəcəkləri barədə danışmalıdırlar. B, C və D hərəkət edə bilərmi? Bəs əgər B və C edə bilsələr, lakin D köhnə alqoritmin davranışının yan təsiri ilə sıx əlaqəlidirsə?

O zaman bu vəziyyətdən necə çıxacağımız barədə danışmalıyıq:

1. Çoxlu daxili API üçün dəstək və D istifadəni dayandırana qədər köhnə alqoritmi köhnəlmiş kimi qeyd edəcək.
2. Biri köhnə interfeysli, biri yenisi ilə çoxlu buraxılış versiyaları üçün dəstək.
3. B, C və D eyni vaxtda qəbul edə bilənə qədər A dəyişikliklərinin buraxılmasını gecikdirin.

Tutaq ki, biz 1, bir neçə API seçmişik. Bu vəziyyətdə iki ədəd kodumuz var. Köhnə və yeni. Bəzi hallarda olduqca rahatdır. Köhnə kodu yenidən yoxlayırıq, onu köhnəlmiş kimi qeyd edirik və D komandası ilə silmə cədvəlini razılaşdırırıq. Poli və mono depolar üçün mahiyyətcə eynidir.

Çox versiyaları buraxmaq üçün bizə bir filial lazımdır. İndi iki komponentimiz var - A1 və A2. B və C komandaları A2, D isə A1-dən istifadə edir. Hər bir komponentin buraxılışa hazır olması lazımdır, çünki D-nin irəliləməsi üçün təhlükəsizlik yeniləmələri və digər səhv düzəlişləri tələb oluna bilər. Bir polirepozitoriyada bunu yaxşı hiss edən uzun ömürlü bir filialda gizlədə bilərik. Monorepozitoriyada kodu yeni modulda yaratmağa məcbur edirik. D komandası hələ də "köhnə" komponentdə dəyişiklik etməli olacaq. Hər kəs burada ödədiyimiz dəyəri görə bilər - indi bizdə iki dəfə çox kod var və A1 və A2-yə tətbiq olunan hər hansı səhv düzəlişləri onların hər ikisinə şamil edilməlidir. Bir polirepozitoriyada budaqlanma yanaşması ilə bu, albalı-pikin arxasında gizlənir. Təkrarlanma olmadığı üçün dəyəri daha aşağı hesab edirik. Praktiki nöqteyi-nəzərdən xərclər eynidir: siz onlardan birini silənə qədər iki eyni kod bazasını quracaq, buraxacaq və saxlayacaqsınız. Fərq ondadır ki, monorepozitoriya ilə bu ağrı birbaşa və görünür. Bu daha pisdir və bu yaxşıdır.

Nəhayət, üçüncü nöqtəyə gəldik. Buraxılış gecikməsi. Ola bilər ki, A tərəfindən edilən dəyişikliklər A komandasının həyatını yaxşılaşdırsın. Vacib, lakin təcili deyil. Sadəcə gecikdirə bilərikmi? Polirepozitoriyada biz bunu artefaktı sancmaq üçün itələyirik. Əlbəttə ki, biz bunu D komandasına deyirik. Yaxalayana qədər köhnə versiyada qalın! Bu sizi qorxaq rolunu oynamağa vadar edir. A komandası D komandasının getdikcə köhnəlmiş versiyadan istifadə etməsinə məhəl qoymadan öz komponenti üzərində işləməyə davam edir (bu, D Komandasının problemidir, onlar axmaqdır). Bu arada, D komandası, ümumiyyətlə, bu barədə danışsalar, A komandasının kod sabitliyinə diqqətsiz münasibəti haqqında zəif danışır. Aylar keçir. Nəhayət, D komandası yeniləmənin mümkünlüyünə baxmaq qərarına gəlir, lakin A-da yalnız daha çox dəyişiklik var. A komandası D-ni nə vaxt və necə sındırdıqlarını çətinliklə xatırlayır. Təkmilləşdirmə daha ağrılıdır və daha uzun çəkəcək. Hansı ki, onu prioritet yığından daha da aşağı göndərir. A-da bizi filial etməyə məcbur edən bir təhlükəsizlik problemimiz olan günə qədər. A komandası keçmişə qayıtmalı, D sabit olduğu nöqtəni tapmalı, orada problemi həll etməli və onu sərbəst buraxılmağa hazırlamalıdır. Bu, insanların de-fakto etdiyi seçimdir və bu, ən pis seçimdir. Bir-birimizə məhəl qoymadığımız müddətcə həm A, həm də D komandası üçün yaxşı görünür.

Bir monorepozitoriyada üçüncü həqiqətən bir seçim deyil. Vəziyyətlə iki yoldan biri ilə məşğul olmaq məcburiyyətindəsiniz. İki buraxılış filialına sahib olmağın xərclərini görməlisiniz. Geriyə uyğunluğu pozan yeniləmələrdən özünüzü qorumağı öyrənin. Amma ən əsası: çətin söhbətdən qaça bilməzsiniz.

Mənim təcrübəmə görə, komandalar böyüdükdə, bütün sistemi nəzərə almaq artıq mümkün deyil və bu, ən vacib hissədir. Sistemdə ixtilafın görünməsini yaxşılaşdırmalısınız. Siz aktiv şəkildə çalışmalısınız ki, komandalar öz komponentlərindən uzaqlaşsınlar və digər komandaların və istehlakçıların işinə baxsınlar.

Bəli, siz polyrepository problemini həll etməyə çalışan alətlər yarada bilərsiniz. Lakin böyük müəssisələrdə davamlı çatdırılma və avtomatlaşdırmanın öyrədilməsi təcrübəm mənə bunu deyir: əlavə alətlərdən istifadə etmədən standart davranış görmək gözlədiyiniz davranışdır. Polirepozitoriyanın standart davranışı izolyasiyadır, bütün məqam budur. Bir monorepozitoriyanın standart davranışı paylaşılan məsuliyyət və şəffaflıqdır, bütün məqam budur. Hər iki halda, kobud kənarları hamarlaşdıracaq bir alət yaradacağam. Bir lider olaraq hər dəfə monorepozitoriya seçəcəyəm, çünki alətlər mənim istədiyim mədəniyyəti gücləndirməlidir və mədəniyyət kiçik qərarlardan və komandanın gündəlik işindən irəli gəlir.

Sorğuda yalnız qeydiyyatdan keçmiş istifadəçilər iştirak edə bilər. Daxil olunxahiş edirəm.

Ən böyük fanatiklər kimlərdir? Dəstəkləyənlər:

• Monorepo

• Pas

• Yanlış sorğu / hər ikisi

33 istifadəçi səs verib. 13 istifadəçi bitərəf qalıb.

Mənbə: www.habr.com