вордпресс

Монорепо наспрам Мулти-Репо: предности и недостаци стратегија репозиторија кода

Постоје две главне стратегије за хостовање и управљање кодом преко Гита: монорепо наспрам мулти-репо. Оба приступа имају своје предности и мане.

Можемо користити било који приступ за било коју кодну базу на било ком језику. Можете користити било коју од ових стратегија за пројекте који садрже неколико библиотека до хиљада њих. Чак и ако укључује неколико чланова тима или стотине, или желите да угостите приватни или отворени код, и даље можете користити монорепо или мулти-репо на основу различитих фактора.

Које су предности и мане сваког приступа? Када треба да користимо једно или друго? Хајде да сазнамо!

Шта су Репос?

Репо (скраћено од репозиторијум) је складиште за све промене и фајлове из пројекта, омогућавајући програмерима да „контролишу верзију” имовине пројекта током његове развојне фазе.

Обично се позивамо на Гит спремишта (као што их пружају ГитХуб, ГитЛаб или Битбуцкет), али концепт се такође примењује на друге системе контроле верзија (као што је Мерцуриал).

Постоје две главне стратегије за хостовање и управљање нашом базом кода преко Гита: монорепо приступ и мулти репо приступ. 🚀 Истражите сваки у овом водичу ⬇Кликните да Твеет

Шта је Монорепо?

Монорепо приступ користи једно спремиште за хостовање целог кода за више библиотека или услуга које чине пројекте компаније. У свом најекстремнијем случају, цела кодна база компаније — која обухвата различите пројекте и кодирана на различитим језицима — смештена је у једном спремишту.

Предности Монорепа

Хостовање целе кодне базе у једном спремишту пружа следеће предности.

Смањује улазне баријере

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

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

Централно лоцирано управљање кодовима

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

На пример, ове карактеристике су драгоцене када проблем обухвата две (или више) подређених библиотека са грешком која постоји у зависној библиотеци. Са више репозиторија, може бити изазовно пронаћи део кода где се проблем дешава.

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

Са монорепо, међутим, и лоцирање проблема са кодом и сарадња на решавању проблема постају једноставнији за постизање.

Безболни рефактори широм апликације

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

Монорепо олакшава извођење свих модификација кода за све библиотеке и његово подношење под једним захтевом за повлачење.

Теже је прекинути суседну функционалност

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

Тимови деле развојну културу

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

Проблеми са Монорепо приступом

Коришћење једног спремишта за цео наш код има неколико недостатака.

Спорији развојни циклуси

Када код за библиотеку садржи преломне промене, због којих тестови за зависне библиотеке не успеју, код се такође мора поправити пре спајања промена.

Ако ове библиотеке зависе од других тимова, који су заузети радом на неком другом задатку и нису у могућности (или нису вољни) да прилагоде свој код како би избегли неометане промене и да би тестови прошли, развој нове функције може да застане.

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

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

Захтева преузимање целе кодне базе

Када монорепо садржи сав код за компанију, он може бити огроман, који садржи гигабајте података. Да би допринео било којој библиотеци која се налази у њој, свако би захтевао преузимање целог спремишта.

Суочавање са огромном базом кода подразумева лошу употребу простора на нашим чврстим дисковима и спорију интеракцију са њом. На пример, свакодневне радње као што је извршење git status или претраживање у бази кода помоћу редовног израза може потрајати много секунди или чак минута дуже него што би то било са вишеструким репо.

Неизмењене библиотеке могу бити нове верзије

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

Рачвање је теже

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

Шта је мулти-репо?

Мулти-репо приступ користи неколико спремишта за смештај више библиотека или услуга пројекта које је развила компанија. У свом најекстремнијем случају, он ће угостити сваки минимални скуп кода за вишекратну употребу или самосталне функционалности (као што је микросервис) у свом спремишту.

Предности Мулти-Репо-а

Хостовање сваке библиотеке независно од свих других пружа мноштво предности.

Индепендент Либрари Версионинг

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

Имати независну верзију за сваку библиотеку помаже у дефинисању стабла зависности за апликацију, омогућавајући нам да конфигуришемо коју верзију сваке библиотеке да користимо.

Независна службена саопштења

Пошто спремиште садржи само код за неку услугу и ништа друго, оно може имати сопствени циклус примене, независно од напретка у апликацијама које му приступају.

Услуга може да користи циклус брзог објављивања као што је континуирана испорука (где се нови код примењује након што прође све тестове). Неке библиотеке које приступају услузи могу да користе спорији циклус издања, као што су оне које производе ново издање само једном недељно.

Помаже у дефинисању контроле приступа широм организације

Само чланови тима укључени у развој библиотеке морају бити додати у одговарајуће спремиште и преузети њен код. Као резултат, постоји имплицитна стратегија контроле приступа за сваки слој у апликацији. Они који су укључени у библиотеку ће добити права на уређивање, а сви остали можда неће имати приступ спремишту. Или им се може дати право читања, али не и уређивање.

Омогућава тимовима да раде аутономно

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

Проблеми са приступом са више репо

Коришћење више спремишта може довести до неколико проблема.

Библиотеке морају стално бити поново синхронизоване

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

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

Сходно томе, тим који није у стању да сустигне може на крају да се држи застареле верзије библиотеке која зависи од тога. Овај исход ће имати импликације на апликацију (у смислу безбедности, брзине и других разматрања), а јаз у развоју библиотека може само да постане већи.

Маи Фрагмент Теамс

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

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

Монорепо вс Мулти-Репо: примарне разлике

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

Њихова главна разлика се тиче њиховог времена када чланови тима доносе одлуке: или унапред за монорепо или касније за мулти-репо.

Хајде да детаљније анализирамо ову идеју.

Пошто су све библиотеке независно верзионисане у мулти-репо-у, тим који издаје библиотеку са преломним изменама може то да уради безбедно тако што ће последњем издању доделити нови главни број верзије. Друге групе могу да имају своје зависне библиотеке да се држе старе верзије и да пређу на нову када се њихов код прилагоди.

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

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

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

Уморни сте од подршке за хостинг ВордПресс нижег нивоа 1 без одговора? Испробајте наш тим за подршку светске класе! Погледајте наше планове

Овај приступ приморава тимове да прилагоде све библиотеке у потпуности кад год се мора десити промена за једну библиотеку. Сви тимови су принуђени да разговарају једни са другима и заједно дођу до решења.

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

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

Хибридни поли-ас-моно приступ

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

Мета је један такав алат. Он организује више спремишта у поддиректоријумима и обезбеђује интерфејс командне линије који извршава исту команду на свим њима истовремено.

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

Да бисмо клонирали мета-складиште и све његове дефинисане вишеструке репозиторије, морамо извршити следеће:

meta git clone [meta repo url]

Мета ће извршити а git clone за свако спремиште и ставите га у поддиректоријум:

Клонирање мета пројекта
Клонирање мета-пројекта. (Извор слике: гитхуб.цом/матеоделнорте/мета)

Од тада па надаље, извршавање meta exec команда ће извршити наредбу у сваком поддиректоријуму. На пример, извршење git checkout master на сваком спремишту се ради овако:

meta exec "git checkout master"

Хибридни моно-као-поли приступ

Други приступ је управљање кодом преко монорепо-а за развој, али копирање кода сваке библиотеке у њено независно спремиште за примену.

Ова стратегија је преовлађујућа у ПХП екосистему јер Пацкагист (главно складиште Цомпосер) захтева УРЛ јавног спремишта за објављивање пакета и није могуће назначити да се пакет налази у поддиректоријуму спремишта.

С обзиром на Пацкагист ограничење, ПХП пројекти и даље могу да користе монорепо за развој, али морају да користе вишерепо приступ за примену.

Да бисмо постигли ову конверзију, можемо извршити скрипту са git subtree split Или користите један од доступних алата који обављају исту логику:

  • Гит Субтрее Сплиттер
  • Гит Субсплит
  • ГитХуб акција за Монорепо Сплит

Ко користи Монорепо против Мулти-Репо-а

Неколико великих технолошких компанија фаворизује монорепо приступ, док су друге одлучиле да користе мулти-репо метод.

Гугл, Фејсбук, Твитер и Убер су јавно јамчили за монорепо приступ. Мицрософт води највећи Гит монорепо на планети за хостовање изворног кода оперативног система Виндовс.

На супротној страни, Нетфлик, Амазон и Лифт су познате компаније које користе мулти-репо приступ.

На страни хибридног поли-ас-моно, Андроид ажурира више складишта, којима се управља као монорепо.

На страни хибрида моно-ас-поли, Симфони чува код за све своје компоненте у монорепо. Поделили су га у независна спремишта за примену (као нпр symfony/dependency-injection symfony/event-dispatcher.)

Примери Монорепо и Мулти-Репо

Вордпрес налог на ГитХуб-у садржи примере монорепо и мулти-репо приступа.

Гутенберг, уређивач блокова ВордПресс-а, састоји се од неколико десетина ЈаваСцрипт пакета. Сви ови пакети се налазе на WordPress/gutenberg монорепо и успео преко Лерне да помогне њихово објављивање у нпм репозиторијуму.

Опенверсе, претраживач за отворено лиценциране медије, хостује своје главне делове у независним репозиторијумима: Фронт-енд, Каталог и АПИ.

Монорепо против Мулти-Репо: како одабрати?

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

  • Колико је велика кодна база? Да ли садржи гигабајте података?
  • Колико људи ће радити на бази кода? Да ли је то око 10, 100 или 1,000?
  • Колико ће пакета бити? Да ли је то око 10, 100 или 1,000?
  • На колико пакета тим треба да ради у датом тренутку?
  • Колико су пакети чврсто повезани?
  • Да ли су укључени различити програмски језици? Да ли им је за покретање потребан одређени софтвер или посебан хардвер?
  • Колико је алата за примену потребно и колико су сложени за постављање?
  • Каква је култура у компанији? Да ли се тимови подстичу на сарадњу?
  • Које алате и технологије тимови знају да користе?

Који приступ треба да примените за своју базу кода? 🤔 Сазнајте више овде 👇Кликните да Твеет

резиме

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

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

Имате ли још питања о монорепос или мулти-репос? Обавестите нас у одељку за коментаре!

Повезани чланци

답글 남기기

이메일 주소는 공개되지 않습니다.

Назад на врх дугмета