In revision control systems, a monorepo ("mono" from Greek μόνος, mónos, 'single, alone' and "repo" short for repository) is a software development strategy where code for many projects is stored in the same repository. As of 2017, various forms of this software engineering practice were over two decades old, but the general concept had only recently been named.[1] Many attempts have been made to differentiate between monolithic applications and other, newer forms of monorepos. [2][3][4]
Google,[5] Facebook,[6] Microsoft,[7] Uber,[8] Airbnb and Twitter[9] all employ very large monorepos with varying strategies to scale build systems and version control software with a large volume of code and daily changes.
Advantages
There are a number of potential advantages to a monorepo over individual repositories:[5][10]
- Ease of code reuse – Similar functionality or communication protocols can be abstracted into shared libraries and directly included by projects, without the need of a dependency package manager.
- Simplified dependency management – In a multiple repository environment where multiple projects depend on a third-party dependency, that dependency might be downloaded or built multiple times. In a monorepo the build can be easily optimized, as referenced dependencies all exist in the same codebase.
- Atomic commits – When projects that work together are contained in separate repositories, releases need to sync which versions of one project work with the other. And in large enough projects, managing compatible versions between dependencies can become dependency hell.[8] In a monorepo this problem can be negated, since developers may change multiple projects atomically.[11]
- Large-scale code refactoring – Since developers have access to the entire project, refactors can ensure that every piece of the project continues to function after a refactor.
- Collaboration across teams – In a monorepo that uses source dependencies (dependencies that are compiled from source),[9] teams can improve projects being worked on by other teams. This leads to flexible code ownership.
Limitations and disadvantages
- Loss of version information – Although not required, some monorepo builds use one version number across all projects in the repository. This leads to a loss of per-project semantic versioning.[12]
- Lack of per-project access control – With split repositories, access to a repository can be granted based upon need. A monorepo allows read access to all software in the project, possibly presenting new security issues.[13]
Note that there are versioning systems in which this limitation is not an issue. For example, when Subversion is used, it's possible to download any part of the repo (even a single directory), and path-based authorization can be used to restrict access to certain parts of a repository. Likewise almost all versioning systems do not require a download of the whole repository [14][15] [16], such that a download size or disk space used is not in principle not different from multiple repos
Scalability challenges
Companies with large projects have come across hurdles with monorepos, specifically concerning build tools and version control systems.[6] Google's monorepo, speculated to be the largest in the world, meets the classification of an ultra-large-scale system[5] and must handle tens of thousands of contributions every day in a repository over 80 terabytes large.[17]
Scaling version control software
Companies using or switching to existing version control software found that software could not efficiently handle the amount of data required for a large monorepo. Facebook and Microsoft chose to contribute to or fork existing version control software Mercurial and Git respectively, while Google eventually created their own version control system.
For more than ten years, Google had relied on Perforce hosted on a single machine. In 2005 Google's build servers could get locked up to 10 minutes at a time. Google improved this to 30 seconds–1 minute in 2010.[18] Due to scaling issues, Google eventually developed its own in-house distributed version control system dubbed Piper.[5]
Facebook ran into performance issues with the version control system Mercurial and made upstream contributions to the client,[19] and in January 2014 made it faster than a competing solution in Git.[20]
In March 2014 Microsoft announced that it switched over to using Git for its monorepo.[21][7] In the transition, Microsoft made substantial upstream contributions to the Git client to remove unnecessary file access and improve handling of large files with Virtual File System for Git.[22]
Scaling build software
Few build tools work well in a monorepo,[9] and flows where builds and continuous integration testing of the entire repository are performed upon check-in will cause performance problems.[12][13] Directed graph builds systems like Buck, Bazel, Pants and Please solve this by compartmentalizing builds and tests to the active area of development.[1]
Twitter began development of Pants in 2011, as both Facebook's Buck and Google's Bazel were closed-source at the time.[23] Twitter open-sourced Pants in 2012 under the Apache 2.0 License.[24]
Please, a Go-based build system, was developed in 2016 by Thought Machine who was also inspired by Google's Bazel and dissatisfied with Facebook's Buck.[25]
Bazel, Buck, Pants and Please all use the same Starlark (formerly Skylark) build language, a domain-specific language based on Python.
Some specialized monorepo build tools, such as Lerna, solve fetching of duplicate dependencies, but lack any directed graph capabilities.[13]
Bit, an open-source monorepo management and built tool introduced in 2018, solve graph-based builds and dependency resolution for multi-component projects.
Comments
Post a Comment
https://gengwg.blogspot.com/