Монорепо

В системах контроля версий монорепо » (« моно » означает «один», а «репо» — сокращение от « репозиторий ) — это стратегия разработки программного обеспечения, при которой код для нескольких проектов хранится в одном и том же репозитории. ^[1] Эта практика восходит как минимум к началу 2000-х годов. ^[2] когда его обычно называли общей кодовой базой. ^[2] Google , ^[3] Мета , ^[4] Майкрософт , ^[5] Убер , ^[6] Airbnb и Твиттер ^[7] все они используют очень большие монорепозитории с различными стратегиями масштабирования систем сборки и программного обеспечения для контроля версий с большим объемом кода и ежедневными изменениями.

Связанная концепция — монолитное приложение , но в то время как монолит объединяет свои подпроекты в один большой проект, монорепозиторий может содержать несколько независимых проектов. ^[8]^[9]^[10]

Преимущества

Монорепозиторий имеет ряд потенциальных преимуществ перед отдельными репозиториями: ^[3]^[11]

Простота повторного использования кода: Подобные функциональные возможности или протоколы связи можно абстрагировать в общие библиотеки и напрямую включать в проекты без необходимости использования менеджера пакетов зависимостей .
Упрощенное управление зависимостями: В среде с несколькими репозиториями, где несколько проектов зависят от сторонней зависимости, эта зависимость может быть загружена или создана несколько раз. В монорепозитории сборку можно легко оптимизировать, поскольку все зависимости, на которые имеются ссылки, существуют в одной базе кода.
Атомарные коммиты: Когда проекты, которые работают вместе, содержатся в отдельных репозиториях, релизы должны синхронизировать версии одного проекта, которые работают с другим. А в достаточно больших проектах управление совместимыми версиями между зависимостями может превратиться в ад зависимостей . ^[6] В монорепозитории эту проблему можно свести на нет, поскольку разработчики могут атомарно изменять несколько проектов. ^[12]
Масштабный рефакторинг кода: Поскольку у разработчиков есть доступ ко всему проекту, рефакторинг может гарантировать, что каждая часть проекта продолжит функционировать после рефакторинга.
Сотрудничество между командами: В монорепозитории, использующем исходные зависимости (зависимости, скомпилированные из исходного кода), ^[7] команды могут улучшать проекты, над которыми работают другие команды. Это приводит к гибкому владению кодом.

Ограничения и недостатки

Потеря информации о версии: Хотя это и не обязательно, некоторые сборки монорепо используют один номер версии для всех проектов в репозитории. Это приводит к потере семантического управления версиями для каждого проекта . ^[13]
Отсутствие контроля доступа к каждому проекту.: При использовании разделенных репозиториев доступ к репозиторию может быть предоставлен в зависимости от необходимости. Монорепозиторий обеспечивает доступ для чтения ко всему программному обеспечению в проекте, что может создавать новые проблемы безопасности. ^[14] Обратите внимание, что существуют системы управления версиями, в которых это ограничение не является проблемой. Например, при использовании Subversion можно загрузить любую часть репозитория (даже один каталог), а авторизацию на основе пути можно использовать для ограничения доступа к определенным частям репозитория.
По умолчанию требуется больше места: При использовании разделенных репозиториев вы по умолчанию получаете только тот проект, который вас интересует. В монорепозитории вы по умолчанию проверяете все проекты. Это может занять значительный объем места для хранения. Хотя в некоторых системах управления версиями предусмотрен механизм частичной проверки, ^[15]^[16]^[17] это сводит на нет некоторые преимущества монорепозитория.

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

Компании с крупными проектами столкнулись с препятствиями при использовании монорепозиториев, особенно в отношении инструментов сборки и систем контроля версий. ^[4] Монорепозиторий Google, предположительно самый крупный в мире, соответствует классификации сверхкрупномасштабной системы. ^[3] и должен обрабатывать десятки тысяч вкладов каждый день в репозитории размером более 80 терабайт. ^[18]

Масштабирование программного обеспечения для контроля версий

Компании, использующие существующее программное обеспечение для контроля версий или перешедшие на него, обнаружили, что оно не может эффективно обрабатывать объем данных, необходимый для большого монорепозитория. Facebook и Microsoft решили внести свой вклад в существующее программное обеспечение для контроля версий Mercurial и Git или развить его соответственно, а Google в конечном итоге создал свою собственную систему контроля версий.

Более десяти лет Google полагался на Perforce, размещенный на одной машине. В 2005 году серверы сборки Google могли быть заблокированы на 10 минут за раз. В 2010 году Google улучшил это значение до 30 секунд–1 минуты. ^[19] Из-за проблем с масштабированием Google в конечном итоге разработала собственную распределенную систему контроля версий, получившую название Piper. ^[3]

Facebook столкнулся с проблемами производительности системы контроля версий Mercurial и внес изменения в исходную версию клиента. ^[20] а в январе 2014 года сделал это быстрее, чем конкурирующее решение на Git. ^[21]

В мае 2017 года Microsoft объявила, что практически все ее инженеры по Windows используют монорепозиторий Git. ^[5] В ходе перехода Microsoft внесла существенный вклад в развитие клиента Git, устранив ненужный доступ к файлам и улучшив обработку больших файлов с помощью виртуальной файловой системы для Git . ^[22]

Масштабирование программного обеспечения для сборки

Немногие инструменты сборки хорошо работают в монорепозитории. ^[7] и потоки, в которых сборки и непрерывное интеграционное тестирование всего репозитория выполняются после регистрации, вызовут проблемы с производительностью. ^[13]^[14] Система сборки, которая обрабатывает зависимости в виде направленного графа (например, Buck , Bazel , Pants или Please ), решает эту проблему путем разделения каждой сборки или теста на активную область разработки. ^[23]

Twitter начал разработку Pants в 2011 году, поскольку исходный код Buck от Facebook и Bazel от Google в то время имели закрытый исходный код. ^[24] Twitter открыл исходный код Pants в 2012 году под лицензией Apache 2.0. ^[25]

Please — это система сборки на основе Go ; он был разработан в 2016 году компанией Thought Machine , чьи разработчики были одновременно вдохновлены Bazel от Google и недовольны Buck от Facebook. ^[26]

Ссылки

^ «Инфраструктура как код | Второе издание» . Мыслительные работы . 2021-02-25 . Проверено 1 декабря 2022 г.
^ Перейти обратно: ^а ^б Марка «Нургл». Коллинз (2001). Программирование игр в Linux . Прима Тех. ISBN 978-0-7615-3255-2 . OCLC 1044194694 .
^ Перейти обратно: ^а ^б ^с ^д Потвин, Рэйчел; Левенберг, Джош (июль 2016 г.). «Почему Google хранит миллиарды строк кода в одном репозитории» . Коммуникации АКМ . 59 (7): 78–87. дои : 10.1145/2854146 . Проверено 20 июля 2018 г.
^ Перейти обратно: ^а ^б Гуд, Дарем; Дождь (7 января 2014 г.). «Масштабирование Mercurial в Facebook — код Facebook» . код ФБ . Проверено 24 июля 2018 г.
^ Перейти обратно: ^а ^б Лардинуа, Фредерик (24 марта 2017 г.). «Microsoft теперь использует Git и GVFS для разработки Windows» . ТехКранч . Проверено 20 июля 2018 г.
^ Перейти обратно: ^а ^б Эйми Люсидо (7 апреля 2017 г.). День технологий Uber: от монорепозитория к мультирепозиторию и обратно . Проверено 24 июля 2018 г.
^ Перейти обратно: ^а ^б ^с Дороти Ордог (5 апреля 2018 г.). Брюки и монорепозитории . Проверено 24 июля 2018 г.
^ Рис, Брок (7 ноября 2017 г.). «От Монолита к Монорепо» . От Монолита к Монорепо. С тех пор, как начал работать в Croud . Проверено 19 марта 2019 г.
^ Савкин Виктор (14 августа 2019 г.). «Заблуждения о монорепозитории: Монорепо != Монолит» . blog.nrwl.io. Проверено 16 июня 2020 г.
^ Оберленер, Маркус (12 июня 2017 г.). «Монорепо в дикой природе» . Проверено 25 июля 2018 г.
^ Брусс, Николя (2019). «Вопрос монорепо и полирепо на крупных предприятиях» . Материалы конференции Компаньон 3-й Международной конференции по искусству, науке и технике программирования . стр. 1–4. дои : 10.1145/3328433.3328435 . ISBN 9781450362573 . S2CID 201670751 . Проверено 7 сентября 2019 г.
^ Сантакроче, Фердинандо; Олссон, Эш; Восс, Расмус; Наребски, Якуб (2016). Git: освоение контроля версий . ООО «Пакт Паблишинг» стр. 756. ISBN 9781787122796 .
^ Перейти обратно: ^а ^б Фарина, Мэтт. «Опасности проектов монорепо — DZone DevOps» . ДЗона . Проверено 20 июля 2018 г.
^ Перейти обратно: ^а ^б Dianrong Gang (16 августа 2017 г.). «Говорим о монорепо» [Говорим о монорепо] 20 (на китайском языке) . Проверено июля 2018 г. .
^ частичный клон git
^ Книга Svn: Разреженные каталоги
^ Перфорс: Клон
^ Мец, Кейд (16 сентября 2015 г.). «Google — это 2 миллиарда строк кода, и все это в одном месте» . ПРОВОДНОЙ . Проверено 20 июля 2018 г.
^ Блох, Дэн. «По-прежнему все на одном сервере: производительность в масштабе» (PDF) . Проверено 23 июля 2018 г.
^ Клэберн, Томас. «Facebook пишет сервер Mercurial на Rust. Это не учение» . Регистр . Проверено 20 июля 2018 г.
^ Блюитт, Алекс (9 января 2014 г.). «Facebook делает Mercurial быстрее, чем Git» . ИнфоQ . Проверено 24 июля 2018 г.
^ Брайт, Питер (24 мая 2017 г.). «Переход Windows на Git почти завершен: 8500 коммитов и 1760 сборок каждый день» . Арс Техника . Проверено 20 июля 2018 г.
^ Хаммант, Пол; Смит, Стив. «Разработка на основе ствола» . магистральная разработка . Проверено 24 июля 2018 г.
^ Мохило, Доминик (10 июня 2016 г.). «8 инструментов сборки в Vergleich: Ant – Buildr – Maven – Bazel – Buck – Gradle – Pants – sbt – JAXenter» [8 сравниваемых инструментов сборки: Ant – Buildr – Maven – Bazel – Buck – Gradle – Pants – sbt]. JAXenter (на немецком языке) . Проверено 20 июля 2018 г.
^ Мур, Мэдисон (3 мая 2016 г.). «GitLab выпускает исправления безопасности, Pants 1.0 и интеграцию Sauce Labs для JIRA — дайджест новостей SD Times: 3 мая 2016 г. — SD Times» . СД Таймс . Проверено 20 июля 2018 г.
^ Эбден, Питер (декабрь 2017 г.). «Пожалуйста — Система сборки мыслительной машины» . Блог. Мыслительная машина . Архивировано из оригинала 28 декабря 2019 г.

[1] «Инфраструктура как код | Второе издание» . Мыслительные работы . 2021-02-25 . Проверено 1 декабря 2022 г.

[Collins2001-2] Перейти обратно: ^а ^б Марка «Нургл». Коллинз (2001). Программирование игр в Linux . Прима Тех. ISBN 978-0-7615-3255-2 . OCLC 1044194694 .

[levenberg-3] Перейти обратно: ^а ^б ^с ^д Потвин, Рэйчел; Левенберг, Джош (июль 2016 г.). «Почему Google хранит миллиарды строк кода в одном репозитории» . Коммуникации АКМ . 59 (7): 78–87. дои : 10.1145/2854146 . Проверено 20 июля 2018 г.

[scaling_mercurial-4] Перейти обратно: ^а ^б Гуд, Дарем; Дождь (7 января 2014 г.). «Масштабирование Mercurial в Facebook — код Facebook» . код ФБ . Проверено 24 июля 2018 г.

[tc_ms_git-5] Перейти обратно: ^а ^б Лардинуа, Фредерик (24 марта 2017 г.). «Microsoft теперь использует Git и GVFS для разработки Windows» . ТехКранч . Проверено 20 июля 2018 г.

[uber_technology_day-6] Перейти обратно: ^а ^б Эйми Люсидо (7 апреля 2017 г.). День технологий Uber: от монорепозитория к мультирепозиторию и обратно . Проверено 24 июля 2018 г.

[pants_monorepos-7] Перейти обратно: ^а ^б ^с Дороти Ордог (5 апреля 2018 г.). Брюки и монорепозитории . Проверено 24 июля 2018 г.

[8] Рис, Брок (7 ноября 2017 г.). «От Монолита к Монорепо» . От Монолита к Монорепо. С тех пор, как начал работать в Croud . Проверено 19 марта 2019 г.

[9] Савкин Виктор (14 августа 2019 г.). «Заблуждения о монорепозитории: Монорепо != Монолит» . blog.nrwl.io. Проверено 16 июня 2020 г.

[10] Оберленер, Маркус (12 июня 2017 г.). «Монорепо в дикой природе» . Проверено 25 июля 2018 г.

[brousse-11] Брусс, Николя (2019). «Вопрос монорепо и полирепо на крупных предприятиях» . Материалы конференции Компаньон 3-й Международной конференции по искусству, науке и технике программирования . стр. 1–4. дои : 10.1145/3328433.3328435 . ISBN 9781450362573 . S2CID 201670751 . Проверено 7 сентября 2019 г.

[santacroce-12] Сантакроче, Фердинандо; Олссон, Эш; Восс, Расмус; Наребски, Якуб (2016). Git: освоение контроля версий . ООО «Пакт Паблишинг» стр. 756. ISBN 9781787122796 .

[farina-13] Перейти обратно: ^а ^б Фарина, Мэтт. «Опасности проектов монорепо — DZone DevOps» . ДЗона . Проверено 20 июля 2018 г.

[talkingabout-14] Перейти обратно: ^а ^б Dianrong Gang (16 августа 2017 г.). «Говорим о монорепо» [Говорим о монорепо] 20 (на китайском языке) . Проверено июля 2018 г. .

[15] частичный клон git

[16] Книга Svn: Разреженные каталоги

[17] Перфорс: Клон

[wired-billions-18] Мец, Кейд (16 сентября 2015 г.). «Google — это 2 миллиарда строк кода, и все это в одном месте» . ПРОВОДНОЙ . Проверено 20 июля 2018 г.

[19] Блох, Дэн. «По-прежнему все на одном сервере: производительность в масштабе» (PDF) . Проверено 23 июля 2018 г.

[20] Клэберн, Томас. «Facebook пишет сервер Mercurial на Rust. Это не учение» . Регистр . Проверено 20 июля 2018 г.

[21] Блюитт, Алекс (9 января 2014 г.). «Facebook делает Mercurial быстрее, чем Git» . ИнфоQ . Проверено 24 июля 2018 г.

[22] Брайт, Питер (24 мая 2017 г.). «Переход Windows на Git почти завершен: 8500 коммитов и 1760 сборок каждый день» . Арс Техника . Проверено 20 июля 2018 г.

[trunk-23] Хаммант, Пол; Смит, Стив. «Разработка на основе ствола» . магистральная разработка . Проверено 24 июля 2018 г.

[mohilo-24] Мохило, Доминик (10 июня 2016 г.). «8 инструментов сборки в Vergleich: Ant – Buildr – Maven – Bazel – Buck – Gradle – Pants – sbt – JAXenter» [8 сравниваемых инструментов сборки: Ant – Buildr – Maven – Bazel – Buck – Gradle – Pants – sbt]. JAXenter (на немецком языке) . Проверено 20 июля 2018 г.

[25] Мур, Мэдисон (3 мая 2016 г.). «GitLab выпускает исправления безопасности, Pants 1.0 и интеграцию Sauce Labs для JIRA — дайджест новостей SD Times: 3 мая 2016 г. — SD Times» . СД Таймс . Проверено 20 июля 2018 г.

[26] Эбден, Питер (декабрь 2017 г.). «Пожалуйста — Система сборки мыслительной машины» . Блог. Мыслительная машина . Архивировано из оригинала 28 декабря 2019 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]