A VCS repository with more than one project
Project: usually library or application, but may be really anything
Naming: projects/sub-projects/modules/sub-modules
Widely adopted by huge companies (like Google, Facebook, Twitter)
Works for relatively small repos too
It's ok to think of it as a fancy name for multi-module builds
May contain all company code
May contain only some parts of a company code
commons |- basic-utils |- models |- database-interactions |-... collectors
|- commons |- youtube
|- twitter |- ...
aggregators
|- commons
|- youtube
commons |- basic-utils |- models |- database-interactions |-... youtube
|- commons |- collector
|- aggregator
twitter
|- collector
|- aggregator ...
3. Super easy code sharing
1. Single source of truth
2. Everything is up-to-date in the code
4. Works not only for code
1. Reproducible builds (for deploying old versions)
2. Build time
3. Remote caching
2. Rare apps deploys may lead to a problems
3. Hard to not touch old code
1. Suitable build tool
4. Build complexity (extensibility of a build tool)
4. Hard to share code with other teams
1. Relatively small codebase (so no big scale problems)
2. Team code is pretty isolated (no code sharing with other teams)
3. A lot of stuff are already shared, or should be shared across many projects
4. Monorepo is a good place for DB management stuff
1. How will it work with an infra-as-code approach?
2. What build tool will we use?
3. How to migrate our existing code to monorepo and not get mad?
1. gradle
2. bazel
By Yury Badalyants
