Превод чланка припремљен за студенте курса „ДевОпс праксе и алати“ у образовном пројекту ОТУС.

Требало би да изаберете монорепозиторијум јер понашање које промовише у вашим тимовима је транспарентност и заједничка одговорност, посебно како тимови расту. У сваком случају, мораћете да инвестирате у алате, али увек је боље ако је подразумевано понашање оно понашање које желите у својим командама.

Зашто причамо о овоме?

Матт Клеин је написао чланак "Монорепос: Молим те, немој!"  (напомена преводиоца: превод на Хабре „Монорепозиторији: молим вас немојте“). Свиђа ми се Мет, мислим да је веома паметан и требало би да прочитате његову тачку гледишта. Он је првобитно објавио анкету на Твитеру:

Превод:
Ове Нове године ћу се расправљати о томе колико су монорепозиторији смешни. 2019 је почела тихо. У духу овога, нудим вам анкету. Ко су велики фанатици? Присталице:
- Монорепо
- Рђа
- Нетачна анкета / обоје

Мој одговор је био: „Ја сам буквално обоје од тих људи. Уместо да причамо о томе како је Руст лек, хајде да погледамо зашто мислим да греши у вези са монорепозиторијумима. Мало о себи. Ја сам ЦТО Цхеф Софтваре-а. Имамо око 100 инжењера, базу кодова која се креће уназад око 11-12 година и 4 главна производа. Део овог кода је у полирепозиторијуму (моја почетна позиција), неки је у монорепозиторијуму (моја тренутна позиција).

Пре него што почнем: сваки аргумент који овде изнесем примениће се на обе врсте спремишта. По мом мишљењу, не постоји технички разлог зашто бисте изабрали једну врсту спремишта у односу на другу. Можете учинити да било који приступ функционише. Радо причам о томе, али ме не занимају вештачки технички разлози због којих је један супериорнији од другог.

Слажем се са првим делом Метове тачке:

Зато што ће монорепозиторијум решити све исте проблеме које решава полирепозиторијум, али ће вас у исто време приморати да чврсто повежете свој код и захтеваће невероватне напоре да повећате скалабилност вашег система контроле верзија.

Мораћете да решавате исте проблеме без обзира да ли изаберете монорепозиторијум или полирепозиторијум. Како објављујете издања? Какав је ваш приступ ажурирањима? Компатибилност? Међусобне зависности пројекта? Који су архитектонски стилови прихватљиви? Како управљате инфраструктуром за изградњу и тестирање? Листа је бескрајна. И све ћеш их решити како растеш. Нема бесплатног сира.

Мислим да је Метов аргумент сличан ставовима које деле многи инжењери (и менаџери) које поштујем. Ово се дешава из перспективе инжењера који ради на компоненти или тима који ради на компоненти. Чујете ствари као што су:

• База кодова је гломазна - не треба ми сво ово смеће.
• Теже је тестирати јер морам да тестирам све ово смеће које ми није потребно.
• Теже је радити са спољним зависностима.
• Треба ми сопствени виртуелни систем контроле верзија.

Наравно, све ове тачке су оправдане. Ово се дешава у оба случаја - у полирепозиторијуму имам своје смеће, поред оног који је потребан за изградњу... Можда ће ми требати и друго смеће. Тако да „једноставно“ креирам алате који проверавају цео пројекат. Или креирам лажно монорепозиторијум са подмодулима. Могли бисмо да шетамо око овога цео дан. Али мислим да Метов аргумент пропушта главни разлог, који сам прилично преокренуо у корист монорепозиторија:

Провоцира комуникацију и показује проблеме

Када одвојимо ризнице, стварамо де фацто проблем координације и транспарентности. Ово одговара начину на који размишљамо о тимовима (нарочито начину на који поједини чланови мисле о њима): ми смо одговорни за одређену компоненту. Радимо у релативној изолацији. Границе су фиксиране за мој тим и компоненту(е) на којој радимо.

Како архитектура постаје сложенија, један тим више не може сам да управља њоме. Веома мали број инжењера има цео систем у глави. Рецимо да управљате дељеном компонентом А коју користе тимови Б, Ц и Д. Тим А рефакторише, побољшава АПИ, а такође мења интерну имплементацију. Као резултат тога, промене нису компатибилне уназад. Какав савет имате?

• Пронађите сва места на којима се користи стари АПИ.
• Да ли постоје места на којима се нови АПИ не може користити?
• Можете ли поправити и тестирати друге компоненте да бисте били сигурни да се не покваре?
• Могу ли ови тимови тренутно тестирати ваше промене?

Имајте на уму да су ова питања независна од типа спремишта. Мораћете да пронађете тимове Б, Ц и Д. Мораћете да разговарате са њима, сазнате време, разумете њихове приоритете. Бар се надамо да хоћете.

Нико заиста не жели ово да уради. Ово је много мање забавно него само поправљање проклетог АПИ-ја. Све је то људски и неуредно. У полирепозиторијуму, можете једноставно да извршите измене, дате је људима који раде на тој компоненти (вероватно не Б, Ц или Д) на преглед и наставите даље. Тимови Б, Ц и Д за сада могу само да остану са својом тренутном верзијом. Они ће бити обновљени када схвате вашу генијалност!

У монорепозиторијуму, одговорност се подразумевано пребацује. Тим А мења своју компоненту и, ако не буде пажљив, одмах разбија Б, Ц и Д. То доводи до тога да се Б, Ц и Д појављују на вратима А, питајући се зашто је Тим А покварио склоп. Ово учи А да не могу да прескоче моју горњу листу. Морају разговарати о томе шта ће урадити. Могу ли Б, Ц и Д да се крећу? Шта ако Б и Ц могу, али Д је уско повезан са споредним ефектом понашања старог алгоритма?

Онда морамо да разговарамо о томе како ћемо изаћи из ове ситуације:

1. Подршка за више интерних АПИ-ја и означиће стари алгоритам као застарео док Д не престане да га користи.
2. Подршка за више верзија издања, једну са старим интерфејсом, једну са новим.
3. Одложите објављивање измена А док Б, Ц и Д не могу истовремено да их прихвате.

Рецимо да смо изабрали 1, неколико АПИ-ја. У овом случају имамо два дела кода. Старо и ново. Сасвим згодно у неким ситуацијама. Поново проверавамо стари код, означавамо га као застарелог и договарамо се о распореду уклањања са Д тимом, у суштини идентичан за поли и моно спремишта.

Да бисмо објавили више верзија, потребна нам је грана. Сада имамо две компоненте - А1 и А2. Тимови Б и Ц користе А2, а Д користи А1. Потребно нам је да свака компонента буде спремна за издавање јер ће можда бити потребне безбедносне исправке и друге исправке грешака пре него што Д може да крене напред. У полирепозиторијуму, ово можемо сакрити у дуговечној грани која се осећа добро. У монорепозиторијуму, присиљавамо да се код креира у новом модулу. Тим Д ће и даље морати да унесе измене у „стару“ компоненту. Свако може да види цену коју плаћамо овде – сада имамо дупло више кода, а све исправке грешака које се примењују на А1 и А2 морају да се примењују на оба. Са приступом гранања у полирепозиторијуму, ово је скривено иза трешње. Сматрамо да је трошак нижи јер нема дуплирања. Са практичне тачке гледишта, цена је иста: изградићете, пустити и одржавати две углавном идентичне базе кода док не избришете једну од њих. Разлика је у томе што је код монорепозиторија овај бол директан и видљив. Ово је још горе, и то је добро.

Коначно смо дошли до треће тачке. Одлагање отпуштања. Могуће је да ће промене које изврши А побољшати животе тима А. Важно, али није хитно. Можемо ли само да одложимо? У полирепозиторијуму гурамо ово да закачимо артефакт. Наравно, ово говоримо Тиму Д. Само останите на старој верзији док не стигнете! Ово те поставља да играш кукавице. Тим А наставља да ради на својој компоненти, игноришући чињеницу да Тим Д користи све старију верзију (то је проблем тима Д, они су глупи). У међувремену, Тим Д лоше говори о немарном односу тима А према стабилности кода, ако о томе уопште говоре. Месеци пролазе. Коначно, Тим Д одлучује да размотри могућност ажурирања, али А има само још промена. Тим А једва се сећа када и како је сломио Д. Надоградња је болнија и трајаће дуже. Што га шаље даље низ приоритетни стек. До дана када имамо безбедносни проблем у А који нас приморава да направимо грану. Тим А мора да се врати у прошлост, да пронађе тачку када је Д био стабилан, да реши проблем тамо и припреми га за пуштање. Ово је де фацто избор који људи праве, и далеко је најгори. Чини се да је добро и за тим А и за тим Д све док можемо да игноришемо једни друге.

У монорепозиторијуму, треће заиста није опција. Приморани сте да се носите са ситуацијом на један од два начина. Морате да видите трошкове поседовања две гране за издавање. Научите да се заштитите од ажурирања која нарушавају компатибилност унатраг. Али најважније: не можете избећи тежак разговор.

По мом искуству, када тимови постану велики, више није могуће имати на уму цео систем, а то је најважнији део. Морате побољшати видљивост неслагања у систему. Морате активно радити на томе да тимови скрену поглед са својих компоненти и погледају рад других тимова и потрошача.

Да, можете креирати алате који покушавају да реше проблем полирепозиторија. Али моје искуство подучавања континуиране испоруке и аутоматизације у великим предузећима ми говори ово: подразумевано понашање без употребе додатних алата је понашање које очекујете да видите. Подразумевано понашање полирепозиторија је изолација, у томе је цела поента. Подразумевано понашање монорепозиторија је подељена одговорност и транспарентност, у томе је цела поента. У оба случаја, направићу алат који ће изгладити грубе ивице. Као вођа, сваки пут ћу изабрати монорепозиторијум јер алати треба да ојачају културу коју желим, а култура долази из малих одлука и свакодневног рада тима.

Само регистровани корисници могу учествовати у анкети. Пријавите се, Добродошао си.

Ко су највећи фанатици? Присталице:

• Монорепо

• Рђа

• Нетачна анкета / обоје

33 корисника је гласало. 13 корисника је било уздржано.

Извор: ввв.хабр.цом