Преводът на статията е подготвен за студенти в курса „DevOps практики и инструменти“ в образователния проект OTUS.

Трябва да изберете монорепозитория, защото поведението, което той насърчава в екипите ви, е прозрачност и колективна отговорност, особено при увеличаване на екипите. Във всеки случай ще трябва да инвестирате в инструменти, но винаги е по-добре, когато поведението по подразбиране е такова, каквото искате да виждате в екипите си.

Защо говорим за това?

Мэт Клайн (Matt Klein) написа статия «Monorepos: Please don’t!» (бележка на преводача: превод на хабре «Монорепозитории: моля, не го правете»). Харесва ми Мэт, мисля, че е много умен и трябва да прочетете неговата гледна точка. Първоначално той публикува анкета в Твитър:

Превод:
В този новогодишен ден ще споря за това колко нелепи са монорепозиториите. 2019 година започна незабележимо. В духа на това ви предлагам анкета. Кои са големите фенове? Подкрепящи:
— Монорепозитория
— Rust
— Неправилна анкета / и двете

Моят отговор беше: «Аз буквално съм и двамата тези човека». Вместо да говоря за това колко наркотик е Rust, нека разгледаме защо мисля, че греши относно монорепозиториите. Малко за мен. Аз съм технически директор на Chef Software. Имаме около 100 инженера, кодова база, която е на около 11–12 години, и 4 основни продукта. Част от този код се намира в полирепозитория (моята стартова позиция), част в монорепозитория (моята текуща позиция).

Преди да започна: всеки аргумент, който посочвам тук, ще се отнася и за двата типа репозитории. Според мен няма технически причини да избирате единия или другия тип репозиторий. Можете да накарате да работи всеки подход. Радвам се да говоря за това, но не ме интересуват изкуствени технически причини, поради които едното превъзхожда другото.

Съгласен съм с първата част от гледната точка на Мэт:

Защото на голямо мащаб монорепозитория ще решава същите проблеми, които решава и полирепозитория, но при това ще провокира силна свързаност на кода ви и ще изисква невероятни усилия за увеличаване на мащабируемостта на системата за контрол на версиите.

Вие ще трябва да решавате подобни проблеми, независимо дали избирате монорепозиторий или полирепозиторий. Как правите релийзите? Какъв е вашият подход към обновленията? Каква е обратната съвместимост? Какви са взаимозависимостите между проектите? Какви архитектурни стилове са приемливи? Как управлявате инфраструктурата за изграждане и тестване? Списъкът е безкраен. И вие ще решавате всичките им, докато растете. Безплатно сирене не съществува.

Мисля, че аргументът на Мэтт е подобен на възгледите на много инженери (и мениджъри), които уважавам. Това е от гледната точка на инженер, работещ върху компонент, или екип, работещ по компонент. Чувате неща като:

Кодовата база е обемиста — не ми трябва всичко това.
Трудно е да се тестват, защото трябва да проверя всичките тези неща, които не ми трябват.
По-трудно е да се работи с външни зависимости.
Имам нужда от свои виртуални системи за управление на версии.

Без съмнение, всички тези точки са основателни. Това е валидно и в полирепозитория — имам своята ненужна част, освен тази, която е необходима за изграждане… Може да ми е необходима още друга ненужна част. Затова просто създавам инструменти, които правят чек-аут на целия проект. Или създавам фалшив монорепозиторий с подмодули. Можем да обсъждаме това цяло ден. Но мисля, че аргументът на Мэтт пропуска основната причина, която доста съм преобърнал в полза на монорепозитория:

Той провокира комуникация и разкрива проблеми.

Когато разделяме репозитории, де факто създаваме проблем с координацията и прозрачността. Това отразява как мислим за екипите (особено как мислят за тях отделни членове): ние носим отговорност за определен компонент. Работим в относителна изолация. Границите се фиксират на моя екип и компонент(и), по които работим.

При усложняване на архитектурата една команда вече не може сама да се справя с нея. Много малко инженери държат цялата система в главата си. Да предположим, че вие управлявате общ компонент А, който се използва от екипи B, C и D. Команда А прави рефакторинг, подобрява API-то и променя вътрешната реализация. В резултат на това промените стават обратно несъвместими. Какъв съвет бихте дали?

Намиране на всички места, където се използва старото API.
Има ли места, където новото API не може да се използва?
Можете ли да поправите и тествате другите компоненти, за да се уверите, че те няма да се счупят?
Могат ли тези екипи да проверят промените ви в момента?

Обърнете внимание, че тези въпроси не зависят от типа на репозитория. Ще трябва да намерите екипи B, C и D. Трябва да говорите с тях, да разберете времето и да разберат приоритетите им. Най-малкото се надяваме, че ще го направите.

Всъщност никой не иска да се занимава с това. Това е далеч по-малко вълнуващо от просто поправяне на проклетото API. Всичко това е човешко и объркано. В полирепозитория можете просто да направите промени, да ги дадете на ревю на тези, които работят по този компонент (вероятно не B, C или D), и да продължите напред. Екипите B, C и D могат временно да останат на текущата си версия. Те ще се обновят, когато осъзнаят вашата гениалност!

В монорепозитория отговорността по подразбиране се прехвърля. Команда А променя своя компонент и, ако не бъде внимателна, веднага чупи B, C и D. Това води до ситуация, в която B, C и D се появяват пред врата на A, учудени защо екип А е счупил сборката. Това учи A, че не могат да пропускат списъка ми по-горе. Те трябва да говорят за това, което се готвят да направят. Могат ли B, C и D да напредват? Какво, ако B и C могат, но D е свързан с нежелан ефект от поведението на стария алгоритъм?

Следва да поговорим за това как ще излезем от тази ситуация:

Поддържане на няколко вътрешни API, като старият алгоритъм е обозначен като остарял, докато D не може да спре да го използва.
Поддържане на няколко версии на релиза, една със стария интерфейс, друга с новия.
Закъсняване на релиза на промените от A, докато одновременно B, C и D не могат да го приемат.

Да приемем, че сме избрали 1, няколко API. В този случай имаме два парчета код. Старият и новият. Доста удобно в някои ситуации. Връщаме стария код обратно, обозначаваме го като остарял (deprecated) и съгласуваме графика за неговото премахване с отбора D. По същество е идентично за поли и монорепозитория.

За да издадем няколко версии, ни е нужна клонка. Сега имаме два компонента — А1 и А2. Отборите B и C използват A2, а D използва A1. Необходимо е всеки компонент да е готов за издание, защото, преди D да може да продължи напред, могат да са нужни актуализации по сигурността и поправки на други грешки. В полирепозитория можем да скрием това в дългосрочна клонка, която се чувства добре. В монорепозитория принудително създаваме код в нов модул. Отборът D все още ще трябва да направи промени в „стария“ компонент. Всеки може да види цената, която плащаме тук — сега имаме два пъти повече код, и всякакви поправки на грешки, които се прилагат за A1 и A2, трябва да се прилагат и за двата. С подхода за използване на клонки в полирепозитория това е скрито зад cherry-pick. Считаме разхода за по-малък, защото там няма дублиране. От практическа гледна точка разходът е един и същ: вие ще създавате, издавате и поддържате две основно идентични кодови бази, докато не можете да премахнете една от тях. Разликата е, че при монорепозитория тази болка е пряма и е на видно място. Това е още по-зле, и това е добре.

Накрая достигнахме до третата точка. Забавяне на релиза. Възможно е промените, внесени от А, да подобрят живота на екип А. Важно, но не спешно. Можем ли просто да забавим? В монорепозиторията ние насочваме това към затвърдяване на артефакта. Разбира се, говорим за това с екип D. Просто останете на старата версия, докато не наваксате! Това настроива игра за търпение. Екип А продължава да работи върху своя компонент, игнорирайки факта, че екип D използва все по-остаряла версия (това е проблем на екип D, те са глупави). Междувременно екип D говори негативно за небрежното отношение на екип А към стабилността на кода, ако изобщо го обсъждат. Минават месеци. Накрая екип D решава да разгледа възможността за актуализация, но промените в A само се увеличават. Екип А едва помни кога и как са счупили D. Актуализацията става по-болезнена и отнема повече време. Което го изпраща още по-надолу в приоритетите. До деня, в който имаме проблем със сигурността в А, който ни принуждава да направим клон. Екип А трябва да се върне назад във времето, да намери момента, в който D е бил стабилен, да поправи проблема там и да го подготви за релиз. Това е де факто избор, който правят хората, и безспорно е най-лошият. Изглежда, че това е добре за екип А и D, стига да можем да игнорираме един друг.

В монорепозитория третата опция наистина не е вариант. Вие сте принудени да се справяте с ситуацията по един от двата начина. Трябва да видите разходите от наличието на два релизни клона. Да се научите да се защитавате от актуализации, които нарушават обратната съвместимост. Но най-важното: няма да избегнете сложен разговор.

От моя опит, когато екипите станат големи, е трудно да се помни цялата система, и това е най-важната част. Трябва да подобрите видимостта на разногласията в системата. Трябва активно да работите, за да накарате екипите да откъснат поглед от своите компоненти и да се запознаят с работата на другите екипи и потребители.

Да, можете да създадете инструменти, които да се опитат да решат проблема с полирепозиториите. Но моят опит в обучението на непрекъсната доставка и автоматизация в големи предприятия ми казва следното: поведението по подразбиране без използването на допълнителни инструменти е това, което очаквате да видите. Поведението на полирепозитория по подразбиране е изолация, това е целта. Поведението на монорепозитория по подразбиране е обща отговорност и прозрачност, това е целта. В двата случая ще създам инструмент, който ще смекчи остри ъгли. Като ръководител, ще избера монорепозиторий всеки път, защото инструментите трябва да укрепват културата, която искам, а културата произтича от малките решения и ежедневната работа на екипа.

Само регистрирани потребители могат да участват в анкетата. Влезте, моля.