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

Шаблон монорепозитория использует единый репозиторий с контролем версий для всех ваших проектов и ресурсов. Вы соберете свои файлы конфигурации на стороне сервера, внешнего интерфейса и инфраструктуры в один репозиторий, в который вносят свой вклад все. Стоит ли использовать его?

Паттерн популярен среди крупных технологических компаний. Google, Microsoft и Facebook входят в число организаций, которые используют монорепозитории. Что делает монорепозиторий таким привлекательным?

Альтернатива

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

Если вы создаете приложение, у вас может быть три репозитория:

• Код на стороне сервера: ваш API (возможно, с дополнительными репозиториями для схем баз данных и документации).
• Проект для Android . Сборка вашего приложения для Android с использованием Java или Kotlin.
• Проект iOS: Objective-C или Swift для вашего приложения iOS.

Здесь все, что составляет ваш бизнес, разделено на отдельные функциональные единицы. С монорепозиторием вы отказываетесь от этой группировки и всегда используете совокупное представление. Все ваши активы принадлежат друг другу и имеют соответствующую версию.

Сотрудничество

Одно из наиболее часто упоминаемых преимуществ монорепозитория касается совместной работы. В монорепозитории все видят все. Это способствует ясности, облегчает открытость и упрощает доступ людей из разных команд к работе друг друга.

Людям легче работать вместе над задачей, даже если она выходит за рамки их обычных обязанностей. В сценарии с несколькими репо вам может потребоваться сначала запросить доступ к соответствующему репозиторию. Это добавляет трения, которых подход монорепозитория полностью избегает.

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

Легкость абстракции

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

В парадигме с несколькими репо вам нужно будет создать новый репозиторий, а затем ссылаться на него в других. Это может быть сборка пакета или использование подмодулей Git. В любом случае потребуется много работы, прежде чем ваш абстрактный код можно будет вернуть в проекты, из которых он был получен.

Процесс более прост, если у вас есть монорепозиторий. Вы можете переместить код в каталог, который имеет смысл, а затем импортировать его туда, где он нужен. «Абстракция» занимает считанные секунды. Такое же удобство, когда пришло время документировать код: вы можете добавить документы в свою общую систему документации.

Мультирепозитории также демонстрируют практические препятствия при абстрагировании кода. Члену команды разработчиков часто не хватает необходимых разрешений GitLab, GitHub или Bitbucket для создания нового репозитория. Это приводит к еще большим накладным расходам, когда руководитель группы должен утвердить новую библиотеку и настроить репозиторий. Монорепозитории помогают отдельным разработчикам создавать повторно используемый код, устраняя специальные процессы абстракции.

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

Скорость развития

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

Монорепозитории уменьшают дублирование действий. Если вам нужно провести рефакторинг, достаточно одной команды «Найти и заменить», чтобы применить изменение ко всей кодовой базе. Меньше переключений между проектами и меньше запросов на проверку.

Участникам предоставляется больше возможностей для самообслуживания. Поскольку информация не хранится в групповых репозиториях, люди лучше подготовлены к поиску нужных им деталей. Это может уменьшить возврат и возврат во время планирования и проверки кода.

Эти характеристики также помогают при рефакторинге существующей системы. Попытка разбить унаследованное приложение на его «интерфейс» и «бэкэнд» может быть неправильным подходом. Изменения на одной стороне неизбежно повлияют на другую, поэтому вам придется постоянно согласовывать два репозитория. Использование монорепозитория помогает быстро реорганизовать большие участки кодовой базы, зная, что вы влияете на всю систему, а не на отдельные компоненты.

Для кого предназначены монорепозитории?

Монорепозитории хорошо подходят для больших команд с несколькими проектами. Преимущества не всегда очевидны в нескольких небольших проектах. Монорепозитории лучше всего работают в масштабах, где подход с несколькими репо будет ощутимо неэффективен.

Монорепозитории — это не то же самое, что монолиты. Монолит обычно описывает приложение, в котором уровни данных и представления перемешаны. Вся система развертывается каждый раз, когда вносятся изменения.

Обычно монорепозитории инкапсулируют несколько систем. У них есть несколько выходных артефактов, таких как API, веб-сайт и мобильное приложение. Не все артефакты нужно создавать для каждого изменения. Монорепозитории предназначены для облегчения совместного использования кода и рефакторинга. Они не предназначены для создания сильно связанной системы, которая искусственно связана друг с другом.

Шаблон подходит не для каждой команды. Во многих случаях проще работать с несколькими репозиториями. Они часто кажутся более логичными, и с ними легче справиться. Вам не нужно будет разрешать конфликты слияния в разрозненных частях системы, и вам будет проще обрабатывать выпуски. Конвейеры CI будут быстрее, так как вы не будете тестировать каждый проект в каждом конвейере.

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

Несколько репозиториев легче интегрировать с программным обеспечением контроля версий, таким как GitHub и GitLab. Эти инструменты предполагают однозначное сопоставление между репозиториями и проектами. Отслеживание проблем и запросов на вытягивание в монорепозитории может быть обременительным. Вам нужно будет усердно использовать теги, чтобы привязать каждую проблему к соответствующему проекту.

Наконец, обратите внимание, что большинство организаций с монорепозиториями используют для их поддержки специализированную инфраструктуру. Git не предназначен для монорепозиториев, и у него могут возникнуть проблемы, если вы достигнете достаточного масштаба. Наличие миллионов объектов в вашей истории коммитов может привести к замедлению работы, когда Git нужно пройти по графику.

Краткое содержание

Шаблон монорепозитория упрощает совместное использование кода и улучшает видимость ваших активов. Это происходит за счет чистой истории коммитов, повышенного риска конфликтов слияния и плохой поддержки популярных инструментов. Вы также можете столкнуться с проблемами производительности по мере роста монорепозитория.

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

Решение об использовании монорепозитория должно основываться на ваших собственных проектах, их межпроектных зависимостях и членах вашей команды. Не смотрите на крупные технологические компании и не ожидайте увидеть их успехи в ваших собственных проектах. Хорошая культура кодирования — это нечто большее, чем тип используемого репозитория. Монорепозитории имеют наибольший смысл, когда люди уже свободно сотрудничают в кросс-проектах по собственному желанию.