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

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

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

Мат Клайн написа статия Monorepos: Моля, недей!  (бележка на преводача: превод на Хабре „Монохранилища: моля, не“). Харесвам Мат, мисля, че е много умен и трябва да прочетете неговата гледна точка. Той първоначално публикува анкетата в Twitter:

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

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

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

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

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

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

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

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

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

Провокира общуването и показва проблеми

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

Тъй като архитектурата става по-сложна, един екип вече не може да я управлява сам. Много малко инженери държат цялата система в главите си. Да приемем, че управлявате споделен компонент A, който се използва от екипи B, C и D. Екип A рефакторира, подобрява 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 е тясно свързано със страничен ефект от поведението на стария алгоритъм?

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

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

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

За да пуснем няколко версии, имаме нужда от клон. Сега имаме два компонента - A1 и A2. Отбори B и C използват A2, а D използва A1. Имаме нужда всеки компонент да е готов за пускане, защото може да са необходими актуализации на защитата и други корекции на грешки, преди D да може да продължи. В полихранилище можем да скрием това в дълготраен клон, който се чувства добре. В монохранилище ние принуждаваме кода да се генерира в нов модул. Отбор D все пак ще трябва да направи промени в "стария" компонент. Всеки може да види цената, която плащаме тук - сега имаме два пъти повече код и всички корекции на грешки, които се отнасят за A1 и A2, трябва да се прилагат и за двата. С подхода за използване на клонове в полихранилище, това е скрито зад черешово избиране. Считаме, че цената е по-малка, защото няма дублиране. От практическа гледна точка цената е една и съща: ще изградите, пуснете и поддържате две основно идентични кодови бази, докато не можете да премахнете една от тях. Разликата е, че в едно хранилище тази болка е директна и видима. По-зле е и е добре.

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

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

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

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

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

Кои са големите фанатици? Поддръжници:

• Монорепозитории

• Ръжда

• Грешна анкета / и двете

33 потребители гласуваха. 13 потребители се въздържаха.

Източник: www.habr.com