Monorepo or Multirepo? Role-Based Repositories
blog.7mind.io
Monorepo or Multirepo? Role-Based Repositories
1–10 of 120 posts
Re: Monorepo or Multirepo? Role-Based Repositories
#2I regularly join projects where someone has decided to place the project's code in half a dozen different repositories.
Even though it's one project.
Even though they refuse to allow a release of a single component - it must all be released together without forwards/backwards compatibility.
I think most of of the time, the mono/multi debate is spoiled by people who feel they can have their cake and eat it too.
Re: Monorepo or Multirepo? Role-Based Repositories
#3The main driver of success in either model is in the tooling and practices invested in it to make it work in an organization. Google is successful with their monorepo because they have invested in building (blaze), source control (piper, code search), and commit to always developing on HEAD. Multirepo is currently easier for most companies because most public tooling (git, package manager) is built around multirepos. One place I see multirepos fall over is awful dependency management practices internally and in open source. Many dependencies quickly become outdated and are not updated in cadence, slowing down writers and consumers. Better tooling can help here but an organization needs real discipline to stay on top of things.
Re: Monorepo or Multirepo? Role-Based Repositories
#4We do multi-repo. It makes it a little slower, cause we have to get commits into our common libs repos (there are two) before we can do app/product repos updated. Using the environment package manager (composer, nom, yarn) rather than git-sub-module helps a lot.
Re: Monorepo or Multirepo? Role-Based Repositories
#5The main driver of success in either model is in the tooling and practices invested in it to make it work in an organization. Google is successful with their monorepo because they have invested in building (blaze), source control (piper, code search), and commit to always developing on HEAD. Multirepo is currently easier for most companies because most public tooling (git, package manager) is built around multirepos.…
Google uses no versioned libraries?
Re: Monorepo or Multirepo? Role-Based Repositories
#6Monorepo shortcomings 1 and 2 seem like bullshit to me. Perforce, the popular monorepo at most companies I've worked at, supports access control. Monorepos do not prevent you from segmenting your code into modules and pushing binary/source packages into source control so that builds can avoid compiling everything(TiVo used to do this, and it worked well when you got the hang of it).
I feel like these debates are often fueled by false arguments. Either way you go, you're going to want to build support tools and processes to tailor your VCS to your local needs.
Re: Monorepo or Multirepo? Role-Based Repositories
#7The main driver of success in either model is in the tooling and practices invested in it to make it work in an organization. Google is successful with their monorepo because they have invested in building (blaze), source control (piper, code search), and commit to always developing on HEAD. Multirepo is currently easier for most companies because most public tooling (git, package manager) is built around multirepos.…
Google uses no versioned libraries?
I think they do, but there is only ever one single version in use - the version in the repo.
Re: Monorepo or Multirepo? Role-Based Repositories
#8One of the things I've done at a couple companies now is flatten multi into mono - it just simplifies everything, it's all deployed as one unit, so easier to track and do changes across different parts of the code base in unison.
I have typically left mobile iOS/Android in separate repos however - they have a different deployment cadence, so you need to manage breaking changes differently anyway.
Re: Monorepo or Multirepo? Role-Based Repositories
#9The main driver of success in either model is in the tooling and practices invested in it to make it work in an organization. Google is successful with their monorepo because they have invested in building (blaze), source control (piper, code search), and commit to always developing on HEAD. Multirepo is currently easier for most companies because most public tooling (git, package manager) is built around multirepos.…
Google uses no versioned libraries?
Libraries internal to Google are kept at the latest and consumers are updated to use the latest APIs. 3rd party libraries are checking into the monorepo at a specific version and everyone uses the same version.
Re: Monorepo or Multirepo? Role-Based Repositories
#10Monorepo shortcomings 1 and 2 seem like bullshit to me. Perforce, the popular monorepo at most companies I've worked at, supports access control. Monorepos do not prevent you from segmenting your code into modules and pushing binary/source packages into source control so that builds can avoid compiling everything(TiVo used to do this, and it worked well when you got the hang of it). I feel like these debates are ofte…
This is all true BUT I think the monorepo as described here is the act of treating all your projects as directly referencing each other.
Sure you could just use a manyrepo style of dependency tracking in a monorepo but I think that's not exactly what the author is exploring.