Монорепозиторий использует единый репозиторий системы контроля версий для всех ваших проектов и файлов. Вы можете объединить все свои файлы конфигурации серверной и клиентской частей и инфраструктуры в один репозиторий, которым смогут пользоваться все. Нужно ли это вам?
Такая структура популярна среди многих крупных IT-компаний. В число организаций, которые используют монорепозиторий, входят такие, как Google, Microsoft и Facebook. Чем же так привлекают монорепозитории?
Альтернативный подход
Альтернатива монорепозитория - мультирепозиторий. В случае мультирепозитория вы создаете новый репозиторий для каждого вашего проекта. Как правило, сразу бывает видно, какой проект достоин отдельного репозитория.
Если вы разрабатываете приложение, то у вас может быть три репозитория:
- серверный код: ваш API (возможно, с дополнительными репозиториями для схем баз данных и документации);
- проект для Android: сборка вашего приложения для Android с помощью Java или Kotlin;
- проект для iOS: Objective-C или Swift для вашего приложения iOS.
Здесь все, что составляет ваше технологическое решение, разделено на отдельные функциональные единицы. Если вы используете монорепозиторий, вы заведомо отказываетесь от такого формата группировки и используете только агрегированное представление. Все ваши файлы составляют одно целое и, соответственно, имеют нумерацию версий.
Совместная работа
Одно из преимуществ монорепозитория, которое довольно часто упоминается, гласит о возможности работать совместно. В монорепозитории все видят все. Это помогает добиться ясности, способствует открытости и упрощает доступ членов разных команд к работе друг друга.
Людям становится легче работать совместно над одной задачей, даже если она выходит за рамки их привычных обязанностей. Если вы используете мультирепозиторий, то для того, чтобы получить доступ к какому-либо репозиторию, возможно, вам придется отправить запрос на доступ к нему. Это создает дополнительные проблемы, которых монорепозиторий полностью избегает.
Монорепозитории предлагают распоряжаться конечной целью, а не отдельными ее элементами. Это позволяет людям ощущать себя более вовлеченными в процесс и, к тому же, они будут лучше информированы о происходящем. Разработчик приложения может не трогать серверные компоненты, но он может «чувствовать», как они формируются параллельно с его собственной работой.
Простота абстрактного представления
Монорепозитории к тому же упрощают абстрактное представление кода. Как правило, в компонентах серверной и клиентской частей используют схожий функционал. Поэтому целесообразно будет обобщить их в отдельную библиотеку.
Когда вы используете мультирепозиторий и создаете в нем новый репозиторий, вам нужно добавить ссылку на него в остальные. Это можно сделать с помощью создания программного пакета или подмодулей Git. Как бы там ни было, прежде чем ваш абстрактный код можно будет вернуть обратно в проекты, из которых он был получен, нужно будет проделать много работы.
Процесс можно сделать намного проще, если у вас есть монорепозиторий. Вы можете поместить код в каталог, а затем импортировать его туда, куда требуется. «Абстрагирование» занимает считанные секунды. Аналогично при документировании кода - вы можете добавить документацию в свою общую систему документации.
Мультирепозитории препятствуют абстрагированию кода. Члены команды разработчиков часто не имеют необходимых прав доступа GitLab, GitHub или Bitbucket для того, чтобы создать новый репозиторий. Это приводит к дополнительным издержкам, когда руководитель должен утвердить новую библиотеку и настроить репозиторий. Монорепозитории помогают отдельным разработчикам создавать многократно используемый код, игнорируя абстрагирование.
Помимо абстрактного представления кода, монорепозитории упрощают сопровождение общих модулей. Когда вы обновляете программный пакет, вам не нужно обновлять всех пользователей этого пакета. Все зависимости находятся в одной и той же базе данных, поэтому вы можете делать на них ссылки, не прибегая к помощи диспетчера пакетов или специального управления версиями.
Скорость разработки
С помощью монорепозитория можно ускорить процесс разработки. Мы упоминали этот момент в предыдущих разделах, но уделим все же ему больше внимания.
Монорепозитории позволяют не выполнять одни и те же действия многократно. Если вам нужно провести перепроектирование программного кода, то достаточно будет одной команды «Найти и заменить» (Find and Replace), чтобы применить изменения ко всей кодовой базе. Итого: меньше переключений между проектами и меньше запросов на включение изменений, которые нужно рассмотреть.
Участники разработки получают больше возможностей для самообслуживания. Так как информация не разбивается на отдельные репозитории, то люди имеют больше возможностей для поиска дополнительных данных. Это может сократить переходы туда-сюда в процессе планирования и анализа программного кода.
Эти свойства также помогают, когда вы перепроектируете уже существующую систему. Попытка разделить унаследованное приложение на «клиентскую часть» и «серверную часть» может оказаться не самой удачной идеей. Изменения, которые вы вносите в одной части, обязательно повлияют и на другую, и вам придется постоянно синхронизировать два репозитория. Монорепозитории помогают быстро перепроектировать большие куски кодовой базы, и при этом вы будете знать, что вы влияете на всю систему, а не на отдельные ее компоненты.
Для кого предназначены монорепозитории?
Монорепозитории хорошо подходят для больших команд разработчиков, которые ведут множество проектов. Если вы используете его для нескольких небольших проектов, то преимущества могут быть не так очевидны. Монорепозитории лучше всего подходят для работы в тех масштабах, для которых использование мультирепозиториев будет не очень эффективно.
Монорепозитории – это не то же самое, что и монолитные системы. Понятие «монолитная система», как правило, относится к приложениям, в которых уровень данных и уровень представления объединены. Каждый раз, когда вы вносите изменения, задействуется вся система.
Как правило, монорепозитории охватывают несколько систем. У них есть несколько выходных компонентов, таких как API, веб-сайт и мобильное приложение. Не все компоненты нужно создавать, когда вы вносите изменения. Монорепозитории предназначены для того, чтобы облегчить совместное использование программы и ее перепроектирование. Они не предназначены для создания системы с сильными искусственными связями.
Такая структура подходит не для каждой команды разработчиков. Зачастую проще работать с несколькими репозиториями, поскольку они кажутся более логичными, и с ними в принципе легче работать. Не будет необходимости разрешать конфликты слияния в разрозненных частях системы, и будет проще работать с версиями программы. Конвейеры непрерывной интеграции будут быстрее, так как вы не будете тестировать все проекты в каждом конвейере.
Отдельные репозитории также предоставляют более понятную историю версий. Истории монорепозиториев засоряются коммитами, которые делаются для каждого проекта в репозитории. Это затрудняет процесс отслеживания развития отдельных компонентов.
Когда репозиториев несколько, то их легче интегрировать с программным обеспечением контроля версий, таким как GitHub и GitLab. Эти инструменты предполагают однозначное соответствие репозиториев и проектов. Отслеживание проблем и запросов на включение изменений в монорепозитории может оказаться проблематичным – необходимо будет активно использовать теги для того, чтобы привязать каждую проблему к соответствующему проекту.
И, наконец, стоит обратить внимание на тот факт, что большая часть организаций с монорепозиториями используют специализированную инфраструктуру для их поддержки. Git не предназначен для монорепозиториев, и поэтому могут возникнуть проблемы, когда вы достигнете какого-то определенного масштаба. Если в вашей истории версий есть миллион объектов, то, если Git необходимо пройти по всем зависимостям, это может привести к уменьшению скорости работы.
Заключение
Монорепозиторий упрощает совместное использование программного кода и улучшает визуальный доступ к вашим файлам. Но при этом он делает историю версий менее понятной, повышает риск конфликтов слияния и имеет слабую поддержку со стороны популярных инструментов. Также вы можете столкнуться с проблемами, связанными с производительностью, по мере роста репозитория.
Прозрачность монорепозитория подходит не для всех случаев. Если вы находитесь в строго контролируемой среде, то вам может потребоваться использовать отдельные репозитории для того, чтобы у вас была возможность обеспечить надлежащий контроль доступа. Монорепозитории также увеличивают риск потери или кражи устройства сотрудника. Люди, которые получили физический доступ к устройству, могут просматривать весь ваш программный код, а не только те проекты, к которым данный сотрудник имеет какое-либо отношение.
Решение, использовать монорепозиторий или нет, должно зависеть от ваших собственных проектов, от их межпроектных зависимостей и членов вашей команды. Не смотрите на крупные IT-компании и не ждите такого же успеха в ваших проектах. Хорошая культура кода – это нечто большее, чем тип репозитория, который вы используете. Монорепозитории больше нужны тогда, когда люди добровольно сотрудничают, работая над общими проектами.
