Пераклад артыкула падрыхтаваны для студэнтаў курса "DevOps практыкі і інструменты" у адукацыйным праекце OTUS.

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

Чаму мы гаворым пра гэта?

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

Пераклад на беларускую:
У гэты навагодні дзень я паспрачаюся аб тым, наколькі недарэчныя монарэпазітары. 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 могуць пакуль проста заставацца на сваёй версіі. Яны абновяцца, калі ўсведамляюць вашу геніяльнасць!

У монорепозитории адказнасць зрушваецца па змаўчанні. Каманда A змяняе свой кампанент і, калі не выявіць асцярожнасці, неадкладна ламае B, C і D. Гэта прыводзіць да таго, што B, C і D з'яўляюцца ў дзвярэй A, дзівячыся, чаму каманда A зламала зборку. Гэта вучыць A таму, што яны не могуць прапусціць мой спіс вышэй. Яны павінны казаць аб тым, што яны збіраюцца рабіць. Ці могуць B, C і D рухацца? Што, калі B і C могуць, але D быў цесна злучаны з пабочным эфектам паводзін старога алгарытму?

Затым мы павінны пагаварыць аб тым, як мы выйдзем з гэтай сітуацыі:

1. Падтрымка некалькіх унутраных API, пры гэтым стары алгарытм будзе пазначаны састарэлым, пакуль D не зможа спыніць яго выкарыстоўваць.
2. Падтрымка некалькіх версій рэлізаў, адна са старым інтэрфейсам, адна з новым.
3. Затрымка рэлізу змен A датуль, пакуль адначасова B, C і D не змогуць прыняць яго.

Дапусцім, мы выбралі 1, некалькі API. У гэтым выпадку ў нас ёсць два кавалка кода. Стары і новы. Даволі зручна ў некаторых сітуацыях. Мы вяртаем стары код назад, пазначаем састарэлым (deprecated) і ўзгадняем графік яго выдалення з камандай D. Па сутнасці ідэнтычна для полі і для монорепозитория.

Для рэлізу некалькіх версій нам патрэбна галіна. Цяпер у нас ёсць два кампаненты - А1 і А2. Каманды B і C выкарыстоўваюць A2, а D выкарыстоўвае A1. Нам трэба, каб кожны кампанент быў готаў да рэлізу, таму што, перш чым D зможа рухацца далей, могуць запатрабавацца абнаўленні бяспекі і выпраўленні іншых памылак. У полірэпазітары мы можам схаваць гэта ў доўгажывучых галінцы, якая адчувае сябе добра. У монорепозитории мы прымусова ствараем код у новым модулі. Камандзе D усё яшчэ давядзецца ўносіць змены ў «стары» кампанент. Кожны можа ўбачыць кошт, які мы тут плацім - у нас цяпер удвая больш кода, і любыя выпраўленні памылак, якія прымяняюцца да A1 і A2, павінны прымяняцца для іх абодвух. З падыходам выкарыстання галінак у полірэпазітары гэта ўтоена за cherry-pick. Мы лічым кошт як меншы, таму што там няма дубліравання. З практычнага пункту гледжання, кошт аднолькавая: вы будзеце ствараць, выпускаць і падтрымліваць дзве, у асноўным ідэнтычныя, базы кода да таго часу, пакуль не зможаце выдаліць адну з іх. Розніца ў тым, што ў монорепозитория гэты боль прамы і яна навідавоку. Гэта яшчэ горш, і гэта добра.

Нарэшце мы дабраліся да трэцяга пункта. Затрымка рэлізу. Магчыма, што змены, унесеныя А, палепшаць жыццё каманды А. Важна, але не тэрмінова. Ці можам мы проста затрымаць? У полірэпазітары мы падштурхоўваем гэта да замацавання артэфакта. Вядома, мы гаворым аб гэтым камандзе D. Проста заставайцеся на старой версіі, пакуль не дагоніце! Гэта настройвае на гульню ў баязліўца. Каманда A працягвае працаваць над сваім кампанентам, ігнаруючы той факт, што каманда D выкарыстоўвае ўсё больш састарэлую версію (гэта праблема каманды D, яны дурныя). Тым часам каманда D кажа дрэнна аб неасцярожным стаўленні каманды A да стабільнасці кода, калі яны наогул кажуць пра гэта. Праходзяць месяцы. Нарэшце, каманда D вырашае зірнуць на магчымасць абнаўлення, але змен у A стала толькі больш. Каманда А ледзь памятае, калі і як яны зламалі D. Абнаўленне больш балюча і зойме больш часу. Што адпраўляе яго далей уніз па стэку прыярытэтаў. Да таго дня, пакуль у нас не ўзнікне праблема бяспекі ў А, што прымушае нас рабіць галінку. Каманда A павінна вярнуцца назад у часе, знайсці момант, калі D быў стабільным, выправіць тамака праблему і зрабіць яго гатовым да рэлізу. Гэта дэ-факта выбар, які робяць людзі, і ён, безумоўна, найгоршы. Падаецца, што гэта добра як для каманды A, так і для D, пакуль мы можам ігнараваць адзін аднаго.

У монорепозитории трэці - сапраўды не варыянт. Вы змушаны спраўляцца з сітуацыяй адным з двух спосабаў. Вам трэба бачыць выдаткі наяўнасці двух рэлізных галінак. Навучыцца абараняць сябе ад абнаўленняў, якія ламаюць зваротную сумяшчальнасць. Але галоўнае: вам не пазбегнуць складанай размовы.

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

Так, вы можаце стварыць прылады, якія паспрабуюць вырашыць праблему полірэпазітароў. Але мой досвед навучання бесперапыннай пастаўцы (continuous delivery) і аўтаматызацыі на буйных прадпрыемствах кажа мне наступнае: паводзіны па змаўчанні без выкарыстання дадатковых прылад - гэта тыя паводзіны, якія вы чакаеце бачыць. Паводзіны полірэпазітара па змаўчанні - ізаляцыя, вось і ўвесь сэнс. Паводзіны монорепозитория па змаўчанні - гэта агульная адказнасць і празрыстасць, вось і ўвесь сэнс. У абодвух выпадках я збіраюся стварыць прыладу, які дазволіць згладзіць вострыя куты. Як кіраўнік, я буду выбіраць монарэпазітар кожны раз, таму што інструменты павінны ўмацоўваць культуру, якую я хачу, а культура зыходзіць з малюсенькіх рашэнняў і штодзённай працы каманды.

Толькі зарэгістраваныя карыстачы могуць удзельнічаць у апытанні. Увайдзіце, Калі ласка.

Хто вялікія фанатыкі? Прыхільнікі:

• Манарэпазіторыя

• Іржа

• Няправільнае апытанне / і тыя і тыя

Прагаласавалі 33 карыстальніка. Устрымаліся 13 карыстальнікаў.

Крыніца: habr.com