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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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