Курс студенттері үшін дайындалған мақаланың аудармасы «DevOps тәжірибелері мен құралдары» OTUS білім беру жобасында.

Сіз монорепозиторийді таңдауыңыз керек, себебі ол сіздің командаларыңыздағы мінез-құлық ашықтық пен ортақ жауапкершілік болып табылады, әсіресе командалар өскен сайын. Қалай болғанда да, құралдарды инвестициялауға тура келеді, бірақ әдепкі әрекет пәрмендеріңізде қалаған әрекет болса, әрқашан жақсы.

Неліктен бұл туралы айтып отырмыз?

Бұл мақаланы Мэтт Клейн жазды "Монорепос: Өтінемін, жасама!"  (аудармашының ескертпесі: Хабредегі аударма «Монорепозиторийлер: жасамаңыз»). Маған Мэтт ұнайды, менің ойымша, ол өте ақылды және оның көзқарасын оқу керек. Ол сауалнаманы алдымен Twitter-де жариялады:

Аударма:
Осы Жаңа жыл күні мен монорепозиторийлердің қаншалықты күлкілі екендігі туралы айтқым келеді. 2019 жыл тыныш басталды. Осыған орай мен сіздерге сауалнама ұсынамын. Үлкен фанаттар кімдер? Қолдаушылар:
- Монорепо
- тот
- Қате сауалнама / екеуі де

Менің жауабым: «Мен екі адаммын». Rust қалай есірткі екендігі туралы айтудың орнына, оның монорепозиторийлер туралы неге қателесетінін қарастырайық. Өзіңіз туралы аздап. Мен Chef Software компаниясының техникалық директорымын. Бізде шамамен 100 инженер, шамамен 11-12 жыл бұрынғы кодтық база және 4 негізгі өнім бар. Бұл кодтың кейбіреулері полирепозиторийде (менің бастапқы орным), кейбіреулері монорепозиторийде (менің қазіргі орным).

Бастамас бұрын: осы жерде айтқан әрбір дәлел репозиторийлердің екі түріне де қолданылады. Менің ойымша, репозиторийдің бір түрін екіншісінен таңдаудың техникалық себебі жоқ. Сіз кез келген тәсілді жұмыс істей аласыз. Мен бұл туралы айтуға қуаныштымын, бірақ біреудің екіншісінен артық болуының жасанды техникалық себептері мені қызықтырмайды.

Мен Мэтттің бірінші бөлігімен келісемін:

Өйткені масштабта монорепозиторий полирепозиторий шешетін барлық бірдей мәселелерді шешеді, бірақ сонымен бірге сізді кодты тығыз байланыстыруға мәжбүрлейді және сіздің нұсқаңызды басқару жүйеңіздің ауқымдылығын арттыру үшін керемет күш салуды талап етеді.

Сіз монорепозиторийді немесе полирепозиторийді таңдағаныңызға қарамастан бірдей мәселелерді шешуге тура келеді. Сіз шығарылымдарды қалай шығарасыз? Жаңартуларға деген көзқарасыңыз қандай? Кері үйлесімділік? Айқас жоба тәуелділіктері? Қандай архитектуралық стильдер қолайлы? Құру және сынақ инфрақұрылымын қалай басқарасыз? Тізім шексіз. Ал сіз олардың барлығын өскен сайын шешесіз. Тегін ірімшік жоқ.

Менің ойымша, Мэтттің дәлелі мен құрметтейтін көптеген инженерлер (және менеджерлер) бөлісетін көзқарастарға ұқсас. Бұл құрамдас бөлікте жұмыс істейтін инженердің немесе құрамдас бөлікте жұмыс істейтін топтың көзқарасы бойынша орын алады. Сіз келесідей нәрселерді естисіз:

• Кодтық база көлемді - маған бұл қоқыстардың бәрі қажет емес.
• Тестілеу қиынырақ, өйткені маған қажет емес барлық қоқыстарды сынауым керек.
• Сыртқы тәуелділіктермен жұмыс істеу қиынырақ.
• Маған виртуалды нұсқаны басқару жүйелері керек.

Әрине, бұл айтылғандардың бәрі орынды. Бұл екі жағдайда да болады – полирепозиторийде құрастыруға қажеттіден басқа өзімнің керексіз заттарым бар... Маған басқа керексіз заттар да керек болуы мүмкін. Сондықтан мен бүкіл жобаны тексеретін құралдарды «жай» жасаймын. Немесе субмодульдермен жалған монорепозиторий жасаймын. Біз бұл жерде күні бойы жүре аламыз. Бірақ менің ойымша, Мэтттің дәлелі негізгі себепті жіберіп алды, мен оны монорепозиторийдің пайдасына қатты аудардым:

Бұл қарым-қатынасты тудырады және проблемаларды көрсетеді

Репозиторийлерді бөлген кезде біз іс жүзінде үйлестіру мен ашықтық мәселесін тудырамыз. Бұл біздің командалар туралы ойлау тәсіліне сәйкес келеді (әсіресе жеке мүшелердің олар туралы ойлау тәсілі): біз белгілі бір құрамдас бөлікке жауаптымыз. Біз салыстырмалы түрде оқшау жұмыс істейміз. Шекаралар менің командамда және біз жұмыс істеп жатқан құрамдас(тар)да бекітілген.

Архитектура күрделене түскен сайын, бір команда оны жалғыз басқара алмайды. Бүкіл жүйені бастарында өте аз инженерлер бар. Сіз B, C және D топтары пайдаланатын ортақ А құрамдас бөлігін басқарасыз делік. A тобы рефакторинг, API жақсарту және ішкі енгізуді өзгертуде. Нәтижесінде өзгертулер кері үйлесімді емес. Қандай кеңес бересіз?

• Ескі API қолданылатын барлық орындарды табыңыз.
• Жаңа API пайдалану мүмкін емес жерлер бар ма?
• Басқа құрамдастардың бұзылмайтынына көз жеткізу үшін оларды түзеп, тексере аласыз ба?
• Бұл командалар өзгерістеріңізді дәл қазір тексере ала ма?

Бұл сұрақтар репозитарий түріне тәуелсіз екенін ескеріңіз. Сізге B, C және D топтарын табу керек. Олармен сөйлесу, уақытты білу, олардың басымдықтарын түсіну қажет. Кем дегенде, сіз жасайсыз деп үміттенеміз.

Мұны шынымен ешкім жасағысы келмейді. Бұл API интерфейсін жөндеуден гөрі әлдеқайда қызықты. Мұның бәрі адамдық және тәртіпсіз. Полирепозиторийде сіз жай ғана өзгертулер енгізе аласыз, оны сол компонентте жұмыс істейтін адамдарға (мүмкін, B, C немесе D емес) қарап шығу үшін беріп, әрі қарай жалғастыра аласыз. B, C және D командалары әзірге өздерінің ағымдағы нұсқасымен қала алады. Олар сіздің данышпандығыңызды түсінгенде жаңарады!

Монорепозиторийде жауапкершілік әдепкі бойынша ауыстырылады. А командасы өз құрамдас бөлігін өзгертеді және абай болмаса, бірден В, С және D сындырады. Бұл В, С және D тобының А тобының есігінің алдында пайда болуына, А командасының жиналысты неліктен бұзғанына таң қалуына әкеледі. Бұл А-ға менің жоғарыдағы тізімімді өткізіп жіберуге болмайтынын үйретеді. Олар не істейтіндерін айту керек. B, C және D қозғала алады ма? Егер B және C мүмкін болса, бірақ D ескі алгоритм әрекетінің жанама әсерімен тығыз байланысты болса ше?

Содан кейін біз бұл жағдайдан қалай шығатынымыз туралы сөйлесуіміз керек:

1. Бірнеше ішкі API интерфейстерін қолдау және D оны пайдалануды тоқтатқанша ескі алгоритмді ескірген деп белгілейді.
2. Біреуі ескі интерфейсі бар, екіншісі жаңасы бар бірнеше шығарылым нұсқаларын қолдау.
3. B, C және D оны бір уақытта қабылдай алғанша, A өзгерістерін шығаруды кейінге қалдырыңыз.

Біз 1, бірнеше API таңдадық делік. Бұл жағдайда бізде екі код бөлігі бар. Ескі және жаңа. Кейбір жағдайларда өте ыңғайлы. Біз ескі кодты қайта тексереміз, оны ескірген деп белгілейміз және D тобымен жою кестесін келісеміз. Негізінде поли және моно репозиторийлер үшін бірдей.

Бірнеше нұсқаны шығару үшін бізге филиал қажет. Енді бізде екі компонент бар - A1 және A2. В және С командалары А2, ал D A1 командасын пайдаланады. Бізге әрбір компонент шығаруға дайын болуы керек, себебі D алға жылжу үшін қауіпсіздік жаңартулары және басқа қателерді түзету қажет болуы мүмкін. Полирепозиторийде біз оны жақсы сезінетін ұзақ өмір сүретін филиалда жасыра аламыз. Монорепозиторийде кодты жаңа модульде жасауға мәжбүрлейміз. D командасы әлі де «ескі» компонентке өзгерістер енгізуі керек. Мұнда біз төлеп жатқан шығынды бәрі көре алады - енді бізде екі есе көп код бар және A1 және A2 үшін қолданылатын қателерді түзету олардың екеуіне де қолданылуы керек. Полирепозиторийдегі тармақталған тәсілмен бұл шие-пиктің артында жасырылады. Қайталану жоқ болғандықтан, құны төмен деп есептейміз. Практикалық тұрғыдан алғанда, құны бірдей: сіз олардың біреуін жоймайынша, екі бірдей кодтық базаны құрасыз, шығарасыз және сақтайсыз. Айырмашылық монорепозиторийде бұл ауырсыну тікелей және көрінеді. Бұл одан да жаман, бұл жақсы.

Ақыры үшінші нүктеге жеттік. Шығару кешігуі. А жасаған өзгерістер А командасының өмірін жақсартуы мүмкін. Маңызды, бірақ шұғыл емес. Біз кешіктіре аламыз ба? Полирепозиторийде біз оны артефактты бекіту үшін итереміз. Әрине, біз мұны D тобына айтып отырмыз. Қуып жеткенше ескі нұсқада болыңыз! Бұл сізді қорқақ ойнауға дайындайды. A тобы D тобының ескірген нұсқасын пайдаланып жатқанын ескермей, өз құрамдас бөліктерімен жұмыс істеуді жалғастыруда (бұл D командасының мәселесі, олар ақымақ). Сонымен қатар, D командасы А командасының код тұрақтылығына немқұрайлы қатынасы туралы нашар айтады, егер олар бұл туралы айтса. Айлар өтеді. Ақырында, D командасы жаңарту мүмкіндігін қарастыруды шешеді, бірақ A тек көбірек өзгерістерге ие. А тобы D қашан немесе қалай сындырғанын әрең есіне түсіреді. Жаңарту әлдеқайда ауыр және ұзағырақ болады. Бұл оны басымдық стекке одан әрі төмен жібереді. Бізді филиал жасауға мәжбүр ететін А-да қауіпсіздік мәселесі болған күнге дейін. А командасы уақытты кері қайтарып, D тұрақты болған нүктені тауып, сол жерде мәселені шешіп, оны босатуға дайын болуы керек. Бұл адамдардың іс жүзінде таңдауы және бұл ең нашар. Бір-бірімізді елемейтін болсақ, бұл A және D командасы үшін жақсы сияқты.

Монорепозиторийде үшінші шын мәнінде опция емес. Сіз жағдайды екі жолдың бірімен шешуге мәжбүрсіз. Сізге екі шығарылым филиалы бар шығындарды көру керек. Өзіңізді кері үйлесімділікті бұзатын жаңартулардан қорғауды үйреніңіз. Бірақ ең бастысы: қиын әңгімеден аулақ бола алмайсыз.

Менің тәжірибемде, командалар үлкен болған кезде, бүкіл жүйені есте сақтау енді мүмкін емес және бұл ең маңызды бөлік. Жүйедегі келіспеушіліктердің көрінуін жақсарту керек. Командалардың өз құрамдас бөліктерінен алыстап, басқа командалар мен тұтынушылардың жұмысына қарауы үшін белсенді жұмыс істеу керек.

Иә, сіз полирепозиторий мәселесін шешуге тырысатын құралдарды жасай аласыз. Бірақ ірі кәсіпорындарда үздіксіз жеткізуді және автоматтандыруды үйретудегі тәжірибем маған мынаны айтады: қосымша құралдарды пайдаланбай әдепкі әрекет - сіз күткен мінез-құлық. Полирепозиторийдің әдепкі әрекеті оқшаулау болып табылады, бұл барлық мәселе. Монорепозиторийдің әдепкі әрекеті ортақ жауапкершілік пен ашықтық болып табылады, бұл барлық мәселе. Екі жағдайда да мен өрескел жиектерді тегістейтін құрал жасаймын. Көшбасшы ретінде мен монорепозиторийді әр уақытта таңдаймын, өйткені құралдар мен қалаған мәдениетті нығайтуы керек, ал мәдениет кішкентай шешімдерден және команданың күнделікті жұмысынан туындайды.

Сауалнамаға тек тіркелген пайдаланушылар қатыса алады. Кіру, өтінемін.

Ең үлкен фанаттар кімдер? Қолдаушылар:

• Монорепо

• тот

• Қате сауалнама / екеуі де

33 қолданушы дауыс берді. 13 пайдаланушы қалыс қалды.

Ақпарат көзі: www.habr.com