Монорепо - Monorepo

В системы контроля версий, а монорепо («моно» от греческого μόνος, mónos, «один, один» и «репо», сокращение от хранилище ) - это стратегия разработки программного обеспечения, в которой код для многих проектов хранится в одном хранилище. По состоянию на 2017 год, различные формы этой практики программной инженерии возникли более двух десятилетий назад, но общая концепция была названа только недавно.[1] Было сделано много попыток провести различие между монолитные приложения и другие, более новые формы монорепозиториев. [2][3][4]

Google,[5] Facebook,[6] Microsoft,[7] Убер,[8] Airbnb и Twitter[9] все используют очень большие монорепозитории с различными стратегиями масштабирования системы сборки и программное обеспечение для контроля версий с большим объемом кода и ежедневными изменениями.

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

У монорепозитория есть ряд потенциальных преимуществ перед индивидуальными репозиториями:[5][10]

  • Легкость повторного использования кода - Аналогичные функции или протоколы связи могут быть абстрагированы в разделяемые библиотеки и напрямую включены в проекты без необходимости в зависимости. менеджер пакетов.
  • Упрощенное управление зависимостями - В среде с несколькими репозиториями, где несколько проектов зависят от сторонней зависимости, эта зависимость может быть загружена или построена несколько раз. В монорепозитории сборку можно легко оптимизировать, поскольку все зависимости, на которые есть ссылки, существуют в одной базе кода.
  • Атомарные коммиты - Когда проекты, которые работают вместе, содержатся в отдельных репозиториях, выпускам необходимо синхронизировать, какие версии одного проекта работают с другим. А в достаточно больших проектах управление совместимыми версиями между зависимостями может стать ад зависимости.[8] В монорепозитории эта проблема может быть устранена, поскольку разработчики могут изменять несколько проектов атомарно.[11]
  • Крупномасштабный рефакторинг кода - Поскольку разработчики имеют доступ ко всему проекту, рефакторы могут гарантировать, что каждая часть проекта продолжит функционировать после рефакторинга.
  • Сотрудничество между командами - В монорепозитории, использующем исходные зависимости (зависимости, которые скомпилированы из исходного кода),[9] команды могут улучшать проекты, над которыми работают другие команды. Это приводит к гибкости владения кодом.

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

  • Потеря информации о версии - Хотя это и не обязательно, некоторые сборки monorepo используют один номер версии для всех проектов в репозитории. Это приводит к потере каждого проекта семантическое управление версиями.[12]
  • Отсутствие контроля доступа к проекту - При использовании разделенных репозиториев доступ к репозиторию может быть предоставлен в зависимости от необходимости. Монорепозиторий обеспечивает доступ для чтения ко всему программному обеспечению в проекте, что может вызвать новые проблемы с безопасностью.[13]

Обратите внимание, что существуют системы управления версиями, в которых это ограничение не является проблемой. Например, когда Subversion , можно загрузить любую часть репо (даже один каталог), а авторизация на основе пути может использоваться для ограничения доступа к определенным частям репозитория. Точно так же почти все системы управления версиями не требуют загрузки всего хранилище [14][15] [16], так что размер загрузки или используемое дисковое пространство в принципе не отличается от нескольких репозиториев

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

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

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

Смотрите также: Управление версиями

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

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

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

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

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

Смотрите также: Автоматизация сборки

Немногие инструменты сборки хорошо работают в монорепозитории,[9] и течет где строит и непрерывное интеграционное тестирование всего репозитория выполняются при регистрации, что вызовет проблемы с производительностью.[12][13] Направленный граф строит такие системы, как Бак, Базель, Штаны и Решите эту проблему, разделив сборки и тесты на активную область разработки.[1]

Twitter начал разработку «Штанов» в 2011 году, так как в то время как Facebook, так и Google Bazel были закрытыми.[23] Открытый исходный код Twitter был открыт в 2012 году под лицензией Apache 2.0.[24]

Пожалуйста, а Идти -система сборки, была разработана в 2016 году компанией Thought Machine, которая также была вдохновлена ​​Bazel от Google и недовольна Buck от Facebook.[25]

Базель, Бак, Штаны и Пожалуйста, используют одно и то же Старларк (бывший Skylark) язык сборки, предметно-ориентированный язык на основе Python.

Некоторые специализированные инструменты сборки монорепозитория, такие как Lerna, решают выборку повторяющихся зависимостей, но не имеют никаких возможностей направленного графа.[13]

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

  1. ^ а б Хаммант, Пол; Смит, Стив. «Магистральная разработка». ствол. Получено 24 июля 2018.
  2. ^ https://medium.com/@brockreece/from-monolith-to-monorepo-19d78ffe9175
  3. ^ https://blog.nrwl.io/misconceptions-about-monorepos-monorepo-monolith-df1250d4b03c
  4. ^ https://medium.com/@maoberlehner/monorepos-in-the-wild-33c6eb246cb9
  5. ^ а б c d Левенберг, Рэйчел Потвин, Джош (июль 2016 г.). «Почему Google хранит миллиарды строк кода в одном репозитории». Коммуникации ACM. Получено 20 июля 2018.
  6. ^ а б ДОБРЫЙ, ДУРЭМ; Дождь. «Масштабирование Mercurial в Facebook - код Facebook». код fb. Получено 24 июля 2018.
  7. ^ а б Купер, Мэтт. «Как мы используем Git в Microsoft - Azure DevOps». Документы Microsoft. Получено 20 июля 2018.
  8. ^ а б Эйми Лучидо (7 апреля 2017 г.). День технологий Uber: с монорепозитория на мультирепо и обратно. Получено 24 июля 2018.
  9. ^ а б c Дороти Ордог (5 апреля 2018 г.). Штаны и монорепозиторы. Получено 24 июля 2018.
  10. ^ Брус, Николя. «Проблема монорепо и полирепо на крупных предприятиях». Цифровая библиотека ACM. Получено 7 сентября 2019.
  11. ^ Сантакроче, Фердинандо; Олссон, Аске; Восс, Расмус; Наребский, Якуб (2016). Git: освоение контроля версий. Packt Publishing Ltd. стр. 756. ISBN  9781787122796.
  12. ^ а б Фарина, Мэтт. «Опасности проектов Monorepo - DZone DevOps». DZone. Получено 20 июля 2018.
  13. ^ а б c 点 融 黑帮 (16 августа 2017 г.). «浅谈 монорепо» [Говоря о монорепозитории]. Соху (на китайском). Получено 20 июля 2018.
  14. ^ git частичный клон
  15. ^ Svn Book: Редкие каталоги
  16. ^ Preforce: клонировать
  17. ^ Мец, Кейд (16 сентября 2015 г.). «Google - это 2 миллиарда строк кода - и все это в одном месте». ПРОВОДНОЙ. Получено 20 июля 2018.
  18. ^ Блох, Дэн. «По-прежнему все на одном сервере: Perforce в масштабе» (PDF). Получено 23 июля 2018.
  19. ^ Клэберн, Томас. «Facebook пишет сервер Mercurial на Rust. Это не упражнение». Реестр. Получено 20 июля 2018.
  20. ^ Блевитт, Алекс (9 января 2014 г.). «Facebook делает Mercurial быстрее, чем Git». InfoQ. Получено 24 июля 2018.
  21. ^ Лардинуа, Фредерик (24 марта 2017 г.). «Microsoft теперь использует Git и GVFS для разработки Windows». TechCrunch. Получено 20 июля 2018.
  22. ^ Яркий, Питер. «Переход Windows на Git почти завершен: 8 500 коммитов и 1760 сборок каждый день». Ars Technica. Получено 20 июля 2018.
  23. ^ Мохило, Доминик (10 июня 2016 г.). «8 Build-Tools im Vergleich: Ant - Buildr - Maven - Bazel - Buck - Gradle - Pants - sbt - JAXenter» [Сравнение 8 инструментов сборки: Ant - Buildr - Maven - Bazel - Buck - Gradle - Pants - sbt]. JAXenter (на немецком). Получено 20 июля 2018.
  24. ^ Мур, Мэдисон (3 мая 2016 г.). «GitLab выпускает исправления безопасности, брюки 1.0 и интеграцию Sauce Labs для JIRA - дайджест новостей SD Times: 3 мая 2016 г. - SD Times». SD Times. Получено 20 июля 2018.
  25. ^ Эбден, Питер (декабрь 2017 г.). «Пожалуйста - система сборки машины мысли». Блог. Мысленная машина. Получено 2019-12-28.


использованная литература