Përkthimi i artikullit është përgatitur për studentët e kursit «Praktikat dhe mjetet DevOps» в образовательном проекте OTUS.

Вы должны выбрать монорепозиторий, потому что поведение, которому он способствует в ваших командах — это прозрачность и коллективная ответственность, особенно при росте команд. В любом случае вам придётся вкладываться в инструментарий, но всегда лучше, когда поведение по умолчанию — это поведение, которое вы хотите видеть в своих командах.

Почему мы говорим об этом?

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

Përkthimi:
В этот новогодний день я поспорю о том, насколько нелепы монорепозитории. 2019 год начался незаметно. В духе этого я предлагаю вам опрос. Кто большие фанатики? Сторонники:
— Монорепозитория
— Rust
— Неправильный опрос / и те и те

Мой ответ был: «Я буквально оба этих человека». Вместо того чтобы говорить о том, какой Rust наркотик, давайте разберёмся, почему я думаю, что он ошибается насчёт монорепозиториев. Немного о себе. Я технический директор Chef Software. У нас около 100 инженеров, кодовая база, насчитывающая около 11–12 лет, и 4 основных продукта. Часть этого кода находится в полирепозитории (моя стартовая позиция), часть в монорепозитории (моя текущая позиция).

Прежде чем я начну: каждый аргумент, который я здесь привожу, будет применён к репозиториям обоих видов. По моему мнению, нет никаких технических причин, по которым вы должны выбрать тот или иной тип репозитория. Вы сможете заставить работать любой подход. Я рад поговорить об этом, но меня не интересуют искусственные технические причины, по которым одно превосходит другое.

Я согласен с первой частью точки зрения Мэтта:

Потому что на большом масштабе монорепозиторий будет решать все те же самые проблемы, которые решает и полирепозиторий, но при этом провоцируя вас к сильной связности вашего кода и требуя невероятных усилий по увеличению масштабируемости вашей системы контроля версий.

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

Я думаю, что аргумент Мэтта похож на взгляды, разделяемые многими инженерами (и менеджерами), которых я уважаю. Это происходит с точки зрения инженера, работающего над компонентом, или команды, работающей над компонентом. Вы слышите такие вещи, как:

Кодовая база громоздкая — мне не нужен весь этот хлам.
Это сложнее тестировать, потому что я должен проверить весь этот хлам, который мне не нужен.
Сложнее работать с внешними зависимостями.
Мне нужны свои виртуальные системы управления версиями.

Безусловно, все эти пункты являются обоснованными. Это происходит в обоих случаях — в полирепозитории у меня есть свой хлам, кроме того, который нужен для сборки… Мне может понадобиться ещё и другой хлам. Поэтому я «просто» создаю инструменты, которые делают чекаут всего проекта. Или я создаю фальшивый монорепозиторий с подмодулями. Мы могли бы ходить весь день вокруг этого. Но я думаю, что аргумент Мэтта пропускает основную причину, которую я довольно сильно перевернул в пользу монорепозитория:

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

Когда мы разделяем репозитории, мы де-факто создаём проблему координации и прозрачности. Это соответствует тому, как мы думаем о командах (особенно тому, как думают о них отдельные участники): мы несём ответственность за определённый компонент. Мы работаем в относительной изоляции. Границы фиксируются на моей команде и компоненте (-ах), над которым мы работаем.

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

Найти все места, где используется старый API.
Есть ли места, где новый API нельзя использовать?
A mund të korrigjoni dhe testoni komponentët e tjerë për të siguruar që ata të mos prishen?
A mund të verifikojnë këto ekipe ndryshimet tuaja tani?

Vini re se këto pyetje nuk varen nga lloji i depozitës. Ju do t'ju duhet të gjeni ekipet B, C dhe D. Duhet të flisni me ta, të kuptoni kohën e tyre, të kuptoni prioritizimet e tyre. Të paktën shpresojmë që t'ia arrini këtij qëllimi.

Askush realisht nuk do të merret me këtë. Është shumë më pak atraktive sesa thjesht të korrigjosh atë damn API. E gjithë kjo është njerëzore dhe e komplikuar. Në një depo poli, mund të bëni ndryshime, t'i dërgoni për rishikim atyre që punojnë mbi këtë komponent (nuk ndoshta B, C ose D) dhe të ecni përpara. Ekipet B, C dhe D mund të mbeten në versionin e tyre aktual për tani. Ata do të përditësohen kur të kuptojnë gjenialitetin tuaj!

Në një depo mono përgjegjësia kalon automatikisht. Ekipi A ndryshon komponentin e tij dhe, nëse nuk tregon kujdes, menjëherë prish B, C, dhe D. Kjo bën që B, C, dhe D të janë në derën e A, duke u habitur pse ekipi A prishi ndërtimin. Kjo i mëson A se nuk mund të anashkalojnë listën time më lart. Ata duhet të flasin rreth asaj që po planifikojnë të bëjnë. A mund të lëvizin B, C dhe D? Çfarë ndodh nëse B dhe C mund të lëvizin, por D është ngushtë i lidhur me efektin anësor të algoritmit të vjetër?

Pastaj, ne duhet të flasim për mënyrën se si do të dalim nga kjo situatë:

Duke mbështetur disa API të brendshme, kurse algoritmi i vjetër do të etiketojë si të përjetshëm, derisa D të mund ta ndalojë përdorimin e tij.
Duke mbështetur disa versione të lëshimeve, një me ndërfaqen e vjetër, një me të rejat.
Duke vonuar lëshimin e ndryshimeve A derisa B, C, dhe D të mund t'i pranojnë ato njëkohësisht.

Supozoni se ne zgjodhëm 1, disa API. Në këtë rast kemi dy copa kodi. E vjetra dhe e re. Mjaft e përshtatshme në disa situata. E kthejmë kodin e vjetër, e etiketojmë si të përjetshëm (deprecated) dhe servoim një plan të tij të fshirjes me ekipin D. Në thelb, është identike për depo poli dhe mono.

Për lëshimin e disa versioneve na nevojitet një degë. Tani kemi dy komponentë - A1 dhe A2. Ekipet B dhe C përdorin A2, ndërsa D përdor A1. Na nevojitet që çdo komponent të jetë i gatshëm për lëshim, sepse përpara se D të mund të ecë përpara, mund të nevojiten përditësime të sigurisë dhe korrigjime të tjera të gabimeve. Në një depo poli, mund ta fshehim këtë në një degë që ka jetëgjatësi, e cila ndihet mirë. Në një depo mono, e detyrojmë kodin të krijohet në një modul të ri. Ekipi D ende duhet të bëjë ndryshime në komponentin 'e vjetër'. Çdokush mund të shohë koston që paguajmë këtu - tani kemi dyfish më shumë kod dhe çdo korrigjim gabimi që zbatohet për A1 dhe A2 duhet të zbatohet për të dy. Me qasjen e përdorimit të degëve në depo poli, kjo është e fshehur pas cherry-pick. E konsiderojmë kostot si më të vogla, sepse nuk ka dublim. Nga një pikëpamje praktike, kostoja është e njëjtë: do të krijoni, lëshoni dhe mbani dy njësi të kodit, kryesisht identike, derisa të mund të fshini një nga ato. Dallimi është se në depo mono dhimbja është direkte dhe e dukshme. Kjo është edhe më keq, dhe kjo është mirë.

Në fund, arritëm në pikën e tretë. Vonimi i lëshimit. Mund të ndodhë që ndryshimet e bërë nga A të përmirësojnë jetën e ekipit A. E rëndësishme, por jo urgjente. A mund të vonojmë thjesht? Në një depo poli, e shtyjmë këtë për të siguruar një artefakt. Natyrisht, ne flasim për këtë me ekipin D. Thjesht qëndroni në versionin e vjetër derisa të arrini! Kjo krijon një rrethanë të frikës. Ekipi A vazhdon të punojë në komponentin e tij, duke injoruar faktin se ekipi D po përdor një version gjithnjë e më të vjetruar (kjo është problemi i ekipit D, ata janë të paditur). Ndërkohë, ekipi D flet keq për qasjen e pa kujdesshme të ekipit A ndaj stabilitetit të kodit, nëse flasin ndonjëherë. Kalojnë muaj. Në fund, ekipi D vendos të shohë mundësinë e përditësimit, por ndryshimet në A janë bërë vetëm më të shumta. Ekipi A mezi e mban mend se kur dhe si ata e prishën D. Përditësimi është më i dhimbshëm dhe do të marrë më shumë kohë, çka e dërgon atë më poshtë në prioritetet. Deri në atë ditë, kur kemi një problem sigurie në A, që na detyron të krijojmë një degë. Ekipi A duhet të kthehet prapa në kohë, të gjejë momentin kur D ishte i qëndrueshëm, të rregullojë atje problemin dhe ta bëjë atë të gatshëm për lëshim. Ky është një zgjedhje de facto që bëjnë njerëzit, dhe padyshim është më e keqja. Duket se është mirë si për ekipin A ashtu edhe për D, përsa kohë që mund të injorojmë njëri-tjetrin.

Në një monorepozitor, i treti— në të vërtetë nuk është një opsion. Ju duhet të përballeni me situatën në një nga dy mënyra. Ju duhet të shihni kostot e ekzistencës së dy degëve të lëshimeve. Të mësoni të mbroni veten nga përditësimet që prishin përputhshmërinë. Por më e rëndësishmja: ju nuk do të shmangni një bisedë të vështirë.

Nga përvoja ime, kur ekipet rriten, nuk ka më mundësi të mbash mend tërë sistemin, dhe kjo është pjesa më e rëndësishme. Ju duhet të përmirësoni dukshmërinë e dallimeve në sistem. Ju duhet të punoni aktivisht për t'i bërë ekipet të heqin vështrimin nga komponentët e tyre dhe të shikojnë punën e ekipeve të tjera dhe të konsumatorëve.

Po, ju mund të krijoni mjete që do të përpiqen të zgjidhin problemin e polirepozitoreve. Por përvoja ime në mësimin e dorëzimit të vazhdueshëm dhe automatizimit në ndërmarrje të mëdha më thotë se: sjellja e paracaktuar pa përdorimin e mjeteve shtesë është ajo sjellje që prisni të shihni. Sjellja e polirepozitorit të paracaktuar është izolimi, kjo është e gjithë pesha. Sjellja e monorepozitorit të paracaktuar është përgjegjësia e përbashkët dhe transparenca, kjo është e gjithë pesha. Në të dy rastet, unë do të krijoj një mjet që do të lehtësojë qoshet e ashpra. Si një lider, do të zgjedh gjithmonë monorepozitor, sepse mjetet duhet të forcojnë kulturën që dua, dhe kultura buron nga vendime të vogla dhe puna e përditshme e ekipit.

Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. Hyni, ju lutemi.