Kurs talabalari uchun tayyorlangan maqolaning tarjimasi "DevOps amaliyotlari va vositalari" OTUS ta'lim loyihasida.

Siz monorepozitoriyni tanlashingiz kerak, chunki u sizning jamoalaringizdagi xatti-harakatlar shaffoflik va umumiy mas'uliyatdir, ayniqsa jamoalar o'sishi bilan. Qanday bo'lmasin, siz asbob-uskunalarga sarmoya kiritishingiz kerak bo'ladi, lekin buyruqlaringizda standart xatti-harakatlar siz xohlagan xatti-harakatlar bo'lsa, har doim yaxshi bo'ladi.

Nega biz bu haqda gapiryapmiz?

Maqolani Mett Klein yozgan "Monorepos: Iltimos, qilmang!"  (tarjimonning eslatmasi: Habré bo'yicha tarjima "Monorepozitoriylar: iltimos qilmang"). Menga Mett yoqadi, menimcha, u juda aqlli va siz uning nuqtai nazarini o'qishingiz kerak. Dastlab u so'rovnomani Twitterda e'lon qildi:

Tarjima:
Ushbu yangi yil kuni men monorepozitoriyalar qanchalik kulgili ekanligi haqida bahslashmoqchiman. 2019 yil tinch boshlandi. Shu ruhda men sizga so'rovnomani taklif qilaman. Katta fanatiklar kimlar? Qo'llab-quvvatlovchilar:
- Monorepo
- zang
- Noto'g'ri so'rov / ikkalasi

Mening javobim shunday bo'ldi: "Men tom ma'noda ikkala odamman". Rustning qanday dori ekanligi haqida gapirishning o'rniga, keling, nima uchun u monorepozitoriyalar haqida noto'g'ri deb o'ylayotganini ko'rib chiqaylik. O'zingiz haqingizda bir oz. Men Chef Software kompaniyasining texnik direktoriman. Bizda 100 ga yaqin muhandislar, taxminan 11-12 yil davom etadigan kod bazasi va 4 ta asosiy mahsulot mavjud. Ushbu kodning ba'zilari polirepozitoriyada (mening boshlang'ich pozitsiyam), ba'zilari monorepozitoriyada (mening hozirgi holatim).

Boshlashdan oldin: men bu erda keltirgan har bir argument ikkala turdagi omborlarga ham tegishli bo'ladi. Menimcha, bir turdagi omborni boshqasidan ko'ra tanlashingizga hech qanday texnik sabab yo'q. Siz har qanday yondashuvni amalga oshirishingiz mumkin. Men bu haqda gapirishdan xursandman, lekin nima uchun birining boshqasidan ustun ekanligining sun'iy texnik sabablari meni qiziqtirmaydi.

Men Mattning birinchi qismiga qo'shilaman:

Chunki miqyosda monorepozitoriya polirepozitoriya hal qiladigan barcha muammolarni hal qiladi, lekin shu bilan birga sizni kodingizni mahkam bog'lashga majbur qiladi va versiyani boshqarish tizimining miqyosini oshirish uchun ajoyib harakatlarni talab qiladi.

Siz monorepozitoriy yoki polirepozitoriyani tanlashingizdan qat'i nazar, bir xil muammolarni hal qilishingiz kerak bo'ladi. Relizlarni qanday chiqarasiz? Yangilanishlarga munosabatingiz qanday? Orqaga moslik? Loyihaning o'zaro bog'liqligi? Qanday me'moriy uslublar qabul qilinadi? Qurilish va sinov infratuzilmangizni qanday boshqarasiz? Ro'yxat cheksizdir. Va siz o'sib ulg'ayganingizda hammasini hal qilasiz. Bepul pishloq yo'q.

Menimcha, Mettning argumenti men hurmat qiladigan ko'plab muhandislar (va menejerlar) tomonidan baham ko'rilgan qarashlarga o'xshaydi. Bu komponent ustida ishlaydigan muhandis yoki komponent ustida ishlaydigan jamoa nuqtai nazaridan sodir bo'ladi. Siz shunday narsalarni eshitasiz:

• Kod bazasi juda katta - menga bu keraksiz narsalar kerak emas.
• Sinab ko'rish qiyinroq, chunki men kerak bo'lmagan barcha keraksiz narsalarni sinab ko'rishim kerak.
• Tashqi bog'liqliklar bilan ishlash qiyinroq.
• Menga virtual versiyani boshqarish tizimlari kerak.

Albatta, bu fikrlarning barchasi o'zini oqlaydi. Bu ikkala holatda ham sodir bo'ladi - polirepozitoriyada mening qurilish uchun zarur bo'lganidan tashqari, o'zimning keraksiz narsalarim bor ... Menga boshqa keraksiz narsalar ham kerak bo'lishi mumkin. Shunday qilib, men butun loyihani tekshiradigan vositalarni "shunchaki" yarataman. Yoki submodullar bilan soxta monorepozitoriya yarataman. Biz kun bo'yi bu atrofida yurishimiz mumkin edi. Ammo, menimcha, Mettning argumenti asosiy sababni o'tkazib yuboradi, men uni monorepozitoriya foydasiga juda qattiq aylantirdim:

Bu muloqotni qo'zg'atadi va muammolarni ko'rsatadi

Biz omborlarni ajratsak, biz amalda muvofiqlashtirish va shaffoflik muammosini yaratamiz. Bu bizning jamoalar haqidagi fikrimizga mos keladi (ayniqsa, alohida a'zolarning ular haqida o'ylash tarzi): biz ma'lum bir komponent uchun javobgarmiz. Biz nisbatan izolyatsiyada ishlaymiz. Chegaralar mening jamoam va biz ishlayotgan komponent(lar)da belgilangan.

Arxitektura murakkablashgani sayin, bitta jamoa uni yolg'iz boshqara olmaydi. Juda kam sonli muhandislar butun tizimni boshidan o'tkazadilar. Aytaylik, siz B, C va D jamoalari tomonidan foydalaniladigan umumiy A komponentini boshqarasiz. A jamoasi refaktoring, APIni takomillashtirish va ichki dasturni o‘zgartirmoqda. Natijada, o'zgarishlar orqaga qarab mos kelmaydi. Qanday maslahatingiz bor?

• Eski API ishlatiladigan barcha joylarni toping.
• Yangi API ishlatib bo'lmaydigan joylar bormi?
• Buzilmasligiga ishonch hosil qilish uchun boshqa komponentlarni tuzatib, sinovdan o'tkaza olasizmi?
• Bu jamoalar sizning o'zgarishlaringizni hozir sinab ko'rishlari mumkinmi?

E'tibor bering, bu savollar ombor turiga bog'liq emas. Siz B, C va D jamoalarini topishingiz kerak bo'ladi. Siz ular bilan gaplashishingiz, vaqtni bilib olishingiz, ularning ustuvorliklarini tushunishingiz kerak bo'ladi. Hech bo'lmaganda, sizga ishonamiz.

Hech kim buni qilishni xohlamaydi. Bu la'nati APIni tuzatishdan ko'ra kamroq qiziqarli. Hammasi insoniy va tartibsiz. Polirepozitoriyda siz shunchaki o'zgartirishlar kiritishingiz, uni ushbu komponentda ishlaydigan odamlarga (ehtimol B, C yoki D emas) ko'rib chiqish uchun berishingiz va davom etishingiz mumkin. B, C va D jamoalari hozirgi versiyalarida qolishlari mumkin. Ular sizning daholigingizni anglaganlarida yangilanadilar!

Monorepozitariyda javobgarlik sukut bo'yicha o'zgaradi. A jamoasi o'z tarkibiy qismini o'zgartiradi va agar ehtiyot bo'lmasa, darhol B, C va D ni buzadi. Bu B, C va D ning A eshigida paydo bo'lishiga olib keladi va A jamoasi nega yig'ilishni buzganiga hayron bo'ladi. Bu A ga yuqoridagi ro'yxatimni o'tkazib yubora olmasligini o'rgatadi. Ular nima qilishlari haqida gapirishlari kerak. B, C va D harakatlana oladimi? Agar B va C mumkin bo'lsa-chi, lekin D eski algoritm xatti-harakatlarining yon ta'siri bilan chambarchas bog'liq bo'lsa?

Keyin bu vaziyatdan qanday chiqishimiz haqida gapirishimiz kerak:

1. Bir nechta ichki API-larni qo'llab-quvvatlaydi va D uni ishlatishni to'xtatmaguncha eski algoritmni eskirgan deb belgilaydi.
2. Bir nechta versiyalarni qo'llab-quvvatlash, biri eski interfeysli, biri yangi.
3. B, C va D bir vaqtning o'zida qabul qila olmaguncha, A o'zgarishlarini chiqarishni kechiktiring.

Aytaylik, biz 1, bir nechta API tanladik. Bunday holda bizda ikkita kod mavjud. Eski va yangi. Ba'zi hollarda juda qulay. Biz eski kodni qaytadan tekshiramiz, uni eskirgan deb belgilaymiz va D jamoasi bilan olib tashlash jadvalini kelishib olamiz. Poly va mono repozitoriylar uchun asosan bir xil.

Bir nechta versiyalarni chiqarish uchun bizga filial kerak. Endi bizda ikkita komponent mavjud - A1 va A2. B va C jamoalari A2 dan, D esa A1 dan foydalanadilar. Biz har bir komponentni chiqarishga tayyor bo'lishimiz kerak, chunki D oldinga siljishidan oldin xavfsizlik yangilanishlari va boshqa xatolarni tuzatish talab qilinishi mumkin. Polirepozitoriyada biz buni yaxshi his qiladigan uzoq umr ko'radigan filialda yashira olamiz. Monorepozitoriyada biz kodni yangi modulda yaratishga majbur qilamiz. D jamoasi hali ham "eski" komponentga o'zgartirish kiritishi kerak. Bu yerda biz to‘layotgan xarajatni hamma ko‘ra oladi – endi bizda ikki baravar ko‘p kod bor va A1 va A2 uchun qo‘llaniladigan har qanday xato tuzatishlar ularning ikkalasiga ham tegishli bo‘lishi kerak. Polyrepozitoriyada dallanma yondashuvi bilan bu gilos-pick orqasida yashiringan. Biz xarajatlarni pastroq deb hisoblaymiz, chunki takrorlash yo'q. Amaliy nuqtai nazardan, xarajat bir xil: siz ulardan birini o'chirguningizcha ikkita bir xil kod bazasini yaratasiz, chiqarasiz va saqlab turasiz. Farqi shundaki, monorepozitoriya bilan bu og'riq to'g'ridan-to'g'ri va ko'rinadi. Bu yanada yomonroq va bu yaxshi.

Nihoyat, uchinchi nuqtaga yetdik. Chiqarish kechikishi. A tomonidan kiritilgan o'zgarishlar A jamoasi hayotini yaxshilashi mumkin. Muhim, lekin shoshilinch emas. Biz shunchaki kechiktira olamizmi? Polirepozitoriyda biz artefaktni mahkamlash uchun uni suramiz. Albatta, biz buni D jamoasiga aytmoqdamiz. Qo‘lga tushguningizcha eski versiyada qoling! Bu sizni qo'rqoq o'ynashga majbur qiladi. A jamoasi o'z komponenti ustida ishlashni davom ettirmoqda, D jamoasi tobora eskirgan versiyadan foydalanayotganiga e'tibor bermasdan (bu D jamoasining muammosi, ular ahmoq). Ayni paytda, D jamoasi A jamoasining kod barqarorligiga beparvo munosabati haqida yomon gapiradi, agar ular bu haqda umuman gapirsalar. Oylar o'tadi. Nihoyat, D jamoasi yangilanish imkoniyatini ko'rib chiqishga qaror qiladi, ammo A faqat ko'proq o'zgarishlarga ega. A jamoasi qachon va qanday qilib D sindirganini deyarli eslay olmaydi. Yangilanish ancha og'riqli va uzoq davom etadi. Bu esa uni ustuvor stekdan pastga yuboradi. Biz bir filiali qilish bizni majbur A xavfsizlik muammosi bor kun qadar. A jamoasi o'z vaqtida orqaga qaytishi, D barqaror bo'lgan nuqtani topishi, muammoni o'sha erda tuzatishi va uni chiqarishga tayyorlab qo'yishi kerak. Bu odamlarning de-fakto tanlovidir va bu eng yomoni. Agar biz bir-birimizni e'tiborsiz qoldira olsak, bu A va D jamoalari uchun yaxshi ko'rinadi.

Monorepozitariyda uchinchisi, albatta, variant emas. Siz vaziyatni ikki yo'ldan birida hal qilishga majbursiz. Siz ikkita reliz filialiga ega bo'lish xarajatlarini ko'rishingiz kerak. O'zingizni orqaga qarab muvofiqlikni buzadigan yangilanishlardan himoya qilishni o'rganing. Lekin eng muhimi: qiyin suhbatdan qochib qutula olmaysiz.

Mening tajribamga ko'ra, jamoalar kattalashganda, butun tizimni yodda tutishning iloji yo'q va bu eng muhim qismdir. Tizimdagi kelishmovchilikning ko'rinishini yaxshilash kerak. Siz jamoalarni o'z tarkibiy qismlaridan uzoqlashishga va boshqa jamoalar va iste'molchilarning ishlariga qarashga majbur qilish uchun faol harakat qilishingiz kerak.

Ha, siz polyrepository muammosini hal qilishga harakat qiladigan vositalarni yaratishingiz mumkin. Ammo yirik korxonalarda uzluksiz yetkazib berish va avtomatlashtirishni o‘rgatish bo‘yicha tajribam menga shuni aytadi: qo‘shimcha vositalardan foydalanmasdan standart xatti-harakatlar siz ko‘rishni kutayotgan xatti-harakatlardir. Polirepozitoriyaning standart xatti-harakati izolyatsiyadir, bu butun nuqta. Monorepozitoriyaning standart xatti-harakati umumiy mas'uliyat va shaffoflikdir, bu butun nuqta. Ikkala holatda ham men qo'pol qirralarni tekislaydigan vositani yarataman. Rahbar sifatida men har safar monorepozitoriyni tanlayman, chunki vositalar men xohlagan madaniyatni kuchaytirishi kerak va madaniyat mayda qarorlar va jamoaning kundalik ishlaridan kelib chiqadi.

So'rovda faqat ro'yxatdan o'tgan foydalanuvchilar ishtirok etishlari mumkin. tizimga kirishiltimos.

Eng katta fanatiklar kimlar? Qo'llab-quvvatlovchilar:

• Monorepo

• zang

• Noto'g'ri so'rov / ikkalasi

33 foydalanuvchi ovoz berdi. 13 nafar foydalanuvchi betaraf qoldi.

Manba: www.habr.com