Моно-репо или мульти-репо? Зачем выбирать одно, если можно и то, и другое?

Многие до сих пор обсуждают «моно-репо» или «мульти-репо». Для тех из вас, кто не знает, что такое моно или мульти-репо, я имею в виду организацию ваших репозиториев. Традиционно было два лагеря, по обеим сторонам которых стояли сторонники.

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

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

Я часто нанимаю подрядчиков, и предоставление им доступа ко ВСЕМ исходному коду не имеет смысла и небезопасно. Наличие нескольких репозиториев позволяет легко предоставлять доступ к подмножествам репозиториев по мере необходимости.
Я настроил непрерывное развертывание для своих проектов. Гораздо проще предоставить каждому репозиторию собственный процесс развертывания. При использовании монорепо требуется дополнительная логика для сортировки каталогов, составляющих различные проекты внутри монорепо.

Для меня это кажется очевидным, но что происходит, когда вы попадаете в 10 разных репозиториев .. 20? 50? 100? более? Управлять становится очень сложно. Никто не хочет, чтобы git клонировал целую кучу разных репозиториев по одному.

Я не первый, кто столкнулся с этой проблемой, и в результате борьбы появился (ныне несуществующий) инструмент под названием gitslave. Gitslave предоставил новую команду gits, которую можно было использовать точно так же, как git, за исключением того, что сразу во многих каталогах. Так родилось мета-репо. И сегодня, благодаря Мэтту Уолтерсу, появился новый, еще более простой выбор: мета.

См. также: Git запустился ?

Meta — это инструмент на основе плагинов, цель которого — упростить создание распределенных систем / библиотек / кодовых баз. Он делает это, предоставляя команды, которые могут выполняться одновременно для любого количества проектов в вашем решении. Нужно создать ветку сразу на пять проектов?

meta git checkout -b feature/my-new-branch

Хотите зафиксировать все изменения функции, над которой вы работаете, которая охватывает несколько служб?

meta git commit -m 'made the feature'

meta выполнит цикл по проектам, добавленным вами в .meta файл, и применит команду к каждому из них. Однако мета работает гораздо больше, чем просто git. Фактически, все мета действительно делает, это организует ваши проекты в файл JSON и предоставляет расширяемое ядро для простого предоставления новых функций с помощью плагинов. meta поставляется с несколькими плагинами, встроенными в ядро, и другие доступны в сообществе.

Ниже я проведу вас через простой процесс создания вашего первого мета-репо.

Содержание

Создание `мета` репозитория
Добавление проектов в ваше мета-репо
Совместное использование
Заключение

Создание `мета` репозитория

Сначала установим meta.

npm i -g meta

Затем давайте создадим новый мета-репозиторий.

mkdir yourProject && cd yourProject
meta init

Будет создан файл .meta со следующим содержимым.

{
 "projects": {}
}

Затем перейдите на GitHub, создайте новый репозиторий и отправьте наше репозиторий.

git init
git add -A
git commit -m “init meta repo”
git remote add origin [email protected]:you/yourProject.git
git push -u origin master

Добавление проектов в ваше мета-репо

Теперь все, что вам нужно сделать, это добавить несколько проектов, что так же просто, как выполнить следующую команду, предоставляемую плагином meta-project. Представим, что у нас есть несколько сервисов, которые мы хотим добавить: userService, graphqlService и appService.

meta project add userService [email protected]:you/userService.git
meta project add graphqlService [email protected]:you/graphqlService.git
meta project add appService [email protected]:you/appService.git

Приведенное выше изменит файл .meta и файл .gitignore, чтобы они выглядели следующим образом:

// .meta
{
  "projects": {
    "userService": "[email protected]:you/userService.git",
    "graphqlService": "[email protected]:you/graphqlService.git",
    "appService": "[email protected]:you/appService.git"
  }
}
// .gitignore
userService
graphqlService
appService

Зафиксируйте и нажмите.

См. также: Как работать над двумя независимыми вещами одновременно, используя ветки git?

Совместное использование

Теперь, когда у вас есть новый разработчик, вы можете просто предоставить ему доступ к соответствующему мета-репозиторию. Если хотите, вы можете создать множество мета-репозиториев. Один для проектов, связанных с DevOps, один со всем для администратора, один с только услугами для бэкэнд-инженера или даже мета-репозиторий, полный других мета-репозиториев. Нарежьте как хотите!

Чтобы клонировать мета-репо, просто запустите следующее:

meta git clone [email protected]:you/yourProject.git

Чтобы синхронизировать дополнительные репозитории, определенные в файле .meta, запустите:

meta git update

Заключение

Когда меня спрашивают, мульти-репо или монорепо, я обычно отвечаю «мета».

Если вам интересно, как создать свой собственный мета-плагин, посмотрите мой другой пост Разработка плагина для мета.

Хотите услышать MY DevOps Journey БЕЗ бесполезных сертификатов AWS? Прочтите прямо сейчас на HackerNoon!

Post Views: 572