Википедия

Монорепозиторий: различия между версиями

Интерактивная навигация по истории
[непроверенная версия][непроверенная версия]
← Предыдущая правкаСледующая правка →
Содержимое удалено Содержимое добавлено
ВизуальныйВики-текст
м Мелкие орфографические правки
м →‎Преимущества: орфография, пунктуация
Строка 1:
{{В инкубаторе}}
В [[Система контроля версий|системе контроля версий]] '''монорепозиторий''' ("mono" от греческого μόνος, мóнос, 'единственный, одинокий' и [[репозиторий]]) является стратегией разработки программного обеспечения, когда код множества подпроектов хранится в одном и том же [[Репозиторий|репозитории]]. К 2017 году некоторым формам этой практики разработки уже более десяти лет, но основное название этой концепции появилось недавно.<ref name=":0">{{Cite web|url=https://trunkbaseddevelopment.com/monorepos/|title=Trunk Based Development|author=paul-hammant|publisher=trunkbaseddevelopment.com|accessdate=2020-06-02}}</ref>. Многие попытки были сделаны для разделения понятий [[:en:Monolithic_application|монолитных приложений]] и прочих более новых форм монорепозиториев. <ref>{{Cite web|lang=en|url=https://medium.com/@brockreece/from-monolith-to-monorepo-19d78ffe9175|title=From Monolith to Monorepo|author=Brock Reece|date=2017-11-07|publisher=Medium|accessdate=2020-06-02}}</ref><ref>{{Cite web|lang=en|url=https://blog.nrwl.io/misconceptions-about-monorepos-monorepo-monolith-df1250d4b03c|title=Misconceptions about Monorepos: Monorepo != Monolith|author=Victor Savkin|date=2019-11-19|publisher=Medium|accessdate=2020-06-02}}</ref><ref>{{Cite web|lang=en|url=https://medium.com/@maoberlehner/monorepos-in-the-wild-33c6eb246cb9|title=Monorepos in the Wild|author=Markus Oberlehner|date=2019-04-04|publisher=Medium|accessdate=2020-06-02}}</ref>.
 
 
Строка 6:
 
== Преимущества ==
Существует ряд возможных преимуществ монорепозиториев над отдельными репозиториями: <ref>{{Cite web|lang=en|url=https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext|title=Why Google Stores Billions of Lines of Code in a Single Repository|author=Rachel Potvin, Josh Levenberg|publisher=cacm.acm.org|accessdate=2020-06-02}}</ref><ref>{{Cite web|lang=EN|url=https://dl.acm.org/doi/abs/10.1145/3328433.3328435|title=The issue of monorepo and polyrepo in large enterprises {{!}} Proceedings of the Conference Companion of the 3rd International Conference on Art, Science, and Engineering of Programming|publisher=dl.acm.org|accessdate=2020-06-02}}</ref>:
 
Простота повторного использования кода -- схожая функциональность или коммуникационные протоколы могут быть выделены в общие библиотеки и напрямую подключаться к проектам без необходимости в [[Система управления пакетами|менеджере пакетов]] для подключения зависимостей.
 
* '''Упрощённое управление зависимостями''' -- в многокомпонентной среде репозитория, где разные проекты зависят от сторонних компонентов, эти компоненты могут загружаться или встраиваться множество раз. В монорепозитории сборка может быть легко оптимизирована, поскольку все зависимые компоненты находятся в одной и той же базе кода.
* '''Атомарные коммиты''' -- когда проекты, работающие вместе, содержатся в раздельных репозиториях, необходимы релизы синхронизирующие версий одного проекта с другим для их совместной работы. В достаточно огромных проектах, борьба за совместимость версий с различными зависимостями может превратиться [[Dependency hell|ад зависимостей]].
* '''Крупномасштабный [[Рефакторинг|рефакторинг кода]]''' -- поскольку разработчики имеют доступ ко всему монолитному проекту, манипуляции по упрощению кода гарантированно сохранят функционирование каждой части проекта после окончания манипуляций.
* '''Сотрудничество между командами''' -- в монорепозитории, использующейиспользующем зависимости с исходным кодом, одни команды легче могут улучшать проекты, над которыми работали другие команды. Это ведёт к более гибкому владению кодом.
 
== Ограничения и недостатки ==
 
* '''Потеря информации версий''' -- и хотя это необязательно, некоторые монорепозитории собираются, используя один номер версии сборки по всем подпроектам в монорепозитории. Это приводит к потере индивидуальной [[Нумерация версий программного обеспечения|нумерации версий]] каждого подпроекта.
* '''Отсутствие надёжности подпроектов''' -- с разделением репозиториев, доступ к репозиторию может быть предоставлен предоставлен по мере необходимости. Монорепозиторий даёт доступ для чтения ко всему программному обеспечению в проекте, что, вероятно, представляет угрозу безопасности.
* '''Больший объём хранилища''' -- с разделёнными репозиториями, вы вносите правки только кв подпроектуподпроект, в котором вы заинтересованы. С монорепозиториями, вам, возможно, потребуется вносить правки ково всемвсе подпроектамподпроекты. Следует отметить, что это не является проблемой в случае использования [[Subversion|SVN]], которая позволяет загружать любую часть репозитория по мере необходимости (даже единственную директорию).
 
== Проблема маштабируемости ==
Компании с большим числом проектов сталкиваются с проблемами маштабируемости монорепозитория, в частности касающихся инструментов сборки и систем контроля версий. <ref name=":2" />. ПредпологаетсяПредполагается, что монорепозиторий компании Google является самым большим в мире и попадаетподпадает под классификацию ультра крупномасштабных систем <ref name=":1" /> и должен обслуживать тысячи разработчиков каждый день в репозитории размером более 80 терабайт. <ref>{{Статья|ссылка=https://www.wired.com/2015/09/google-2-billion-lines-codeand-one-place/|автор=Cade Metz|заглавие=Google Is 2 Billion Lines of Code—And It's All in One Place|год=2015-09-16|издание=Wired|issn=1059-1028}}</ref>.
 
=== Масштабирование системы контроля версий ===
Компании, использующие или переходящие к существующим системам контроля версий обнаружили, что программное обеспечение не могло эффективно обработать количестваколичество данных, необходимыхнеобходимое для огромных монорепозиториев. Facebook и Microsoft решили поддерживать или [[Форк|форкать]] существующие системы контроля версийрепозитории [[Mercurial]] и [[Git]] соответственно, в то время, как Google, в конечном итоге, создала свою собственную систему контроля версий.
 
Более десяти лет Google полагался на [[Perforce]], развёрнутой на единственной машине. В 2005 сервер для сборки Google мог быть единовременно заблокирован до 10 минут, а в 2010 от 30 секунд до 1 минуты. <ref>{{Статья|ссылка=https://storage.googleapis.com/pub-tools-public-publication-data/pdf/39983.pdf|автор=Dan Bloch|заглавие=Still All on One Server: Perforce at Scale|год=2011|язык=English|издание=Google Inc|тип=|месяц=|число=|том=|номер=|страницы=|issn=}}</ref>.▼
 
Facebook столкнулся с проблемами производительности системы контроля версий [[Mercurial]] и внёс вклад в разработку клиента.<ref>{{Cite web|lang=en|url=https://www.theregister.com/2016/10/18/facebook_mercurial_devs_forget_git/|title=Facebook is writing a Mercurial server in Rust. This is not a drill|publisher=www.theregister.com|accessdate=2020-06-02}}</ref>; Вв январе 2014 года сделал его быстрее конкурирующей реализации в [[Git]].▼
 
В марте 2014 Microsoft анонсировала о переходепереход к использованию [[Git]] для собственного монорепозитория. <ref>{{Cite web|lang=en-US|url=https://social.techcrunch.com/2017/05/24/microsoft-now-uses-git-and-gvfs-to-develop-windows/|title=Microsoft now uses Git and GVFS to develop Windows|publisher=TechCrunch|accessdate=2020-06-02}}</ref><ref name=":3" />. В процессе перехода Microsoft внесла существенный вклад в разработку Git клиента для удаления доступа к ненужным файлам и улучшила обработку больших файлов посредством [[:en:Virtual_File_System_for_Git|виртуальной файловой системы для Git]]. <ref>{{Cite web|lang=en-us|url=https://arstechnica.com/information-technology/2017/05/90-of-windows-devs-now-using-git-creating-1760-windows-builds-per-day/|title=Windows switch to Git almost complete: 8,500 commits and 1,760 builds each day|author=Peter Bright|date=2017-05-24|publisher=Ars Technica|accessdate=2020-06-02}}</ref>.▼
▲Более десяти лет Google полагался на [[Perforce]], развёрнутой на единственной машине. В 2005 сервер для сборки Google мог быть единовременно заблокирован до 10 минут, а в 2010 от 30 секунд до 1 минуты. <ref>{{Статья|ссылка=https://storage.googleapis.com/pub-tools-public-publication-data/pdf/39983.pdf|автор=Dan Bloch|заглавие=Still All on One Server: Perforce at Scale|год=2011|язык=English|издание=Google Inc|тип=|месяц=|число=|том=|номер=|страницы=|issn=}}</ref>
 
=== Масштабирование средств сборки ===▼
Лишь несколько инструментов сборки работаетработают хорошо в монорепозитории. Системы, основанные на [[Ориентированный ациклический граф|ориентированном ациклическом графе]], такие как [[:en:Buck_(software)|Buck]], [[:en:Bazel_(software)|Bazel]], Pants и Please, используют обособленные сборки и тесты для активной области разработки. <ref name=":0" />.▼
 
Twitter начал разработку Pants в 2011, поскольку Buck от Facebook и Bazel от Google на тот момент имели закрытый код. <ref>{{Cite web|lang=de-DE|url=https://jaxenter.de/8-build-tools-im-vergleich-ant-buildr-maven-bazel-buck-gradle-pants-sbt-41627|title=8 Build-Tools im Vergleich: Ant – Buildr – Maven – Bazel – Buck – Gradle – Pants – sbt|date=2016-06-10|publisher=JAXenter|accessdate=2020-06-02}}</ref>. Twitter открыла код Pants в 2012 году под лицензией Apache 2.0. <ref>{{Cite web|lang=en-US|url=https://sdtimes.com/apache/gitlab-releases-security-fixes-pants-1-0-sauce-labs-integration-jira-sd-times-news-digest-may-3-2016/|title=GitLab releases security fixes, Pants 1.0, and Sauce Labs integration for JIRA—SD Times news digest: May 3, 2016|date=2016-05-03|publisher=SD Times|accessdate=2020-06-02}}</ref>.▼
▲Facebook столкнулся с проблемами производительности системы контроля версий [[Mercurial]] и внёс вклад в разработку клиента.<ref>{{Cite web|lang=en|url=https://www.theregister.com/2016/10/18/facebook_mercurial_devs_forget_git/|title=Facebook is writing a Mercurial server in Rust. This is not a drill|publisher=www.theregister.com|accessdate=2020-06-02}}</ref> В январе 2014 года сделал его быстрее конкурирующей реализации в [[Git]].
 
 
▲В марте 2014 Microsoft анонсировала о переходе к использованию [[Git]] для собственного монорепозитория. <ref>{{Cite web|lang=en-US|url=https://social.techcrunch.com/2017/05/24/microsoft-now-uses-git-and-gvfs-to-develop-windows/|title=Microsoft now uses Git and GVFS to develop Windows|publisher=TechCrunch|accessdate=2020-06-02}}</ref><ref name=":3" /> В процессе перехода Microsoft внесла существенный вклад в разработку Git клиента для удаления доступа к ненужным файлам и улучшила обработку больших файлов посредством [[:en:Virtual_File_System_for_Git|виртуальной файловой системы для Git]]. <ref>{{Cite web|lang=en-us|url=https://arstechnica.com/information-technology/2017/05/90-of-windows-devs-now-using-git-creating-1760-windows-builds-per-day/|title=Windows switch to Git almost complete: 8,500 commits and 1,760 builds each day|author=Peter Bright|date=2017-05-24|publisher=Ars Technica|accessdate=2020-06-02}}</ref>
 
▲=== Масштабирование средств сборки ===
▲Лишь несколько инструментов сборки работает хорошо в монорепозитории. Системы основанные на [[Ориентированный ациклический граф|ориентированном ациклическом графе]], как [[:en:Buck_(software)|Buck]], [[:en:Bazel_(software)|Bazel]], Pants и Please используют обособленные сборки и тесты для активной области разработки. <ref name=":0" />
 
Система сборки Please, основанная на Go, была разработана в 2016 Thought Machine, вдохновлённой Bazel от Google и недовольной Buck от Facebook. <ref>{{Cite web|url=https://www.thoughtmachine.net/blog/please-the-thought-machine-build-system/|title=Please - the Thought Machine Build System {{!}} Thought Machine|publisher=www.thoughtmachine.net|accessdate=2020-06-02}}</ref>.▼
▲Twitter начал разработку Pants в 2011, поскольку Buck от Facebook и Bazel от Google на тот момент имели закрытый код. <ref>{{Cite web|lang=de-DE|url=https://jaxenter.de/8-build-tools-im-vergleich-ant-buildr-maven-bazel-buck-gradle-pants-sbt-41627|title=8 Build-Tools im Vergleich: Ant – Buildr – Maven – Bazel – Buck – Gradle – Pants – sbt|date=2016-06-10|publisher=JAXenter|accessdate=2020-06-02}}</ref> Twitter открыла код Pants в 2012 под лицензией Apache 2.0. <ref>{{Cite web|lang=en-US|url=https://sdtimes.com/apache/gitlab-releases-security-fixes-pants-1-0-sauce-labs-integration-jira-sd-times-news-digest-may-3-2016/|title=GitLab releases security fixes, Pants 1.0, and Sauce Labs integration for JIRA—SD Times news digest: May 3, 2016|date=2016-05-03|publisher=SD Times|accessdate=2020-06-02}}</ref>
 
▲Система сборки Please, основанная на Go, была разработана в 2016 Thought Machine вдохновлённой Bazel от Google и недовольной Buck от Facebook. <ref>{{Cite web|url=https://www.thoughtmachine.net/blog/please-the-thought-machine-build-system/|title=Please - the Thought Machine Build System {{!}} Thought Machine|publisher=www.thoughtmachine.net|accessdate=2020-06-02}}</ref>
 
 
Bazel, Buck, Pants и Please используют Starlark (ранее Skylark) - [[предметно-ориентированный язык]] сборки, основанный на [[Python]].
 
Некоторые специальные инструменты сборки для монорепозиториев, такие как Lerna, разрешают проблему дублирования зависимостей, но не обладают возможностями [[Ориентированный ациклический граф|ориентированного ациклического графа]].
 
<references />
Источник — https://ru.wikipedia.org/wiki/Монорепозиторий