Monorepo или multirepo

Съдържание:

Резюме
Подробности
Свързани
Бележки

Резюме

Проблем

Нашият проект включва разработването на три основни категории софтуер:

Front-end графични интерфейси
Междинни услуги (middleware)
Back-end сървъри

Когато разработваме, нашата система за контрол на версиите (VCS) за управление на изходния код (SCM) е git.

Трябва да изберем как да използваме git за организиране на кода ни.

Основният избор е да организираме като „monorepo“, „polyrepo“ или „hybrid“:

Monorepo означава, че слагаме всички части в едно голямо хранилище
Polyrepo означава, че слагаме всяка част в собствено хранилище
Hybrid означава някаква комбинация от monorepo и polyrepo

За повече информация вижте https://github.com/joelparkerhenderson/monorepo-vs-polyrepo

Решение

Monorepo, когато организацията/екипът/проектът е относително малък и бързото итериране е с по-висок приоритет от поддържането на стабилност.

Polyrepo, когато организацията/екипът/проектът е относително голям и поддържането на стабилност е с по-висок приоритет от бързото итериране.

Състояние

Взето. Открити сме да преразгледаме, ако/когато станат налични нови инструменти за управление на monorepo и/или polyrepo.

Подробности

Допускания

Целият код, който разработваме, е за предложенията на една организация, а не за широката общественост. Т.е. Broker-Dealer няма за цел да има нещо като доброволци разработчици от широката общественост.

Ограничения

Ограниченията са добре документирани на https://github.com/joelparkerhenderson/monorepo-vs-polyrepo

Позиции

Разгледахме monorepo в стила на Google, Facebook и др. Смятаме, че всички проблеми с мащабирането на monorepo са толкова далеч в бъдещето, че докато ни потрябват, ще можем да използваме същите практики като Google и Facebook.

Разгледахме polyrepo в стила на типични проекти с отворен код в Git, като Google Android, Facebook React и др. Смятаме, че те са най-добрият избор за участие на широката общественост (напр. всеки в света може да работи по кода) и индивидуална достъпност (напр. проектът се използва самостоятелно, без други части).

Аргумент

Когато организацията/екипът/проектът е относително малък, избираме monorepo, защото бързото итериране е значително по-висок приоритет от поддържането на стабилност

Когато организацията/екипът/проектът е относително голям, избираме polyrepo, защото поддържането на стабилност е значително по-висок приоритет от бързото итериране.

Последици

Ако съществува конвейер за CI+CD, може да се наложи да го коригираме за тестване на множество проекти в едно хранилище.

CI+CD може да отнеме повече време за пълно изграждане на monorepo, защото CI+CD може да изгражда всички проекти в monorepo.

Ако организацията/екипът/проектът расте, monorepo ще има проблеми с мащабирането.

Проблемите с мащабирането на monorepo могат да направят преходът към polyrepo все по-ценен.

Преходът от monorepo към polyrepo е значителна devops задача и ще трябва да бъде планиран, управляван и програмиран.

Свързани

Свързани решения

Ще създадем решения за свързани инструменти за управление на monorepo (напр. Google Bazel) и polyrepo (напр. Lyft Refactorator).

Свързани изисквания

Трябва да разработим CI+CD конвейера да работи добре с git.

Свързани артефакти

Очакваме организацията на хранилището да има свързани артефакти за осигуряване на ресурси (provisioning), управление на конфигурацията, тестване и подобни devops области.

Свързани принципи

Лесно обратимо. Ако monorepo не работи на практика или не е желано от ръководството, лесно е да се премине към polyrepo.

Обсебеност от клиента. Ценим довеждането на проекта до клиентите и вярваме, че monorepo може да ни доведе дотам по-бързо от polyrepo, а също да ни помогне да итерираме по-бързо.

Мисли мащабно. Google и Facebook са много силни привърженици на monorepo пред polyrepo, защото всички основни предложения могат да се разработват/тестват/внедряват съгласувано.

Бележки

Добавете бележки тук.