5 ms·

I've worked a bit with "the big monorepo" (though nothing like Google scale) and my impression is that a lot of the benefits fall apart if you don't have people

I've worked a bit with "the big monorepo" (though nothing like Google scale) and my impression is that a lot of the benefits fall apart if you don't have people working to maintain the build environment, automated tests, developer environments. When it takes hours or more to run tests and produce a build it can really slow the team down. The ability to force updates on dependencies in a single big commit can be really worthwhile as long as you're willing to spend the time to build the tools and do the maintenance.

fsloth 10y ago
"When it takes hours or more to run tests and produce a build it can really slow the team down. " I don't think those are necessary artifacts of a monorepo. A huge chunk of code does not mean that every component there is connected.
- deepsun 10y ago
  In Google it is somewhat connected, actually. Sometimes engineers have to run ALL tests over the repo. And it takes hours (better be scheduled overnight!). Although they might have fixed that already.
  - deleted 10y ago
    [deleted]
  - iamchrisle 10y ago
    Kinda. Depends on who you ask. :)
munificent 10y ago
> a lot of the benefits fall apart if you don't have people working to maintain the build environment, automated tests, developer environments. This is absolutely true. Without a very strong culture around testing and deep, continuous investment in infrastructure and tools, a monolithic repo would quickly devolve to being a giant midden heap of code.
- huherto 10y ago
  How is that different on multi-repos ? The total amount of code is the same. You also need to keep build environments(not one but several), dependency management is much harder,etc. I would say that any large project needs a "very strong culture around testing and deep, continuous investment in infrastructure and tools"
  - Domenic_S 10y ago
    In my experience with small teams, maybe one person will take testing & automation seriously. If they've got a couple small codebases to worry about, it's possible for them to manage. One giant codebase would be too much work. Obviously not the way it should be, etc, but reality bites.
    - tamana 10y ago
      So you've got a few small repos with good build infra,and many small repos that don't. Your overall system is still a sibling ship, and you have no economy of scale force multiplying your few people who take infra seriously
- iamchrisle 10y ago
  There are dedicated and volunteer teams that work on the internal tools and a strong testing and accountability culture. Everything is built from source.
hvidgaard 10y ago
I still cannot wrap my head around this. What merit does forcing internal code to update a dependancy have? Having dependencies packaged like NuGet, and using an internal repository, you can always remove a particular version of a dependency if you must, and a build will fail if it cannot automatically use the latest minor version.
- regularfry 10y ago
  It means that I, as a dependency author, can make a breaking change and push not only the updates to my library, but also the updates to all my dependents in a single commit. Using a dependency packaging system like NuGet is a workaround for me not knowing who all my clients are. In a monorepo, I can have perfect knowledge.
  - humanrebar 10y ago
    > Using a dependency packaging system like NuGet is a workaround for me not knowing who all my clients are. Between published manifests and search indexed source code, you would know who all your clients are, even without a monorepo.
  - michaelt 10y ago
    push not only the updates to my library, but also the updates to all my dependents in a single commit. And what's more, you can run all their automated tests and address any problems your changes introduce. Which presumably means regular forced updates aren't the recipe for instability they would otherwise be.
  - gcb0 10y ago
    take debian. you write a new version. push the new package. everyone else's build will fail until they update. its as bad as you describe, but more organized :)
  - cwilkes 10y ago
    Should you know who all your clients are? That seems to be a workaround for not having an adequate testing framework or a contract stating what your code will do. Do open source frameworks know everyone's code that is using it? Plus you do have perfect knowledge if your CI tools builds everything on your commit. Which it will do anyway if you have a monorepo.
erikb 10y ago
Agreed. It's a huge dependency of monorepo that is often not spelled out directly. Probably the reason is that the people who successfully implemented monorepos already live so deeply in that continuous integration world, maybe even continuous deployment, so that they don't even know anymore that a huge part of the world has not moved there yet (despite trying for a decade).
wtbob 10y ago
> a lot of the benefits fall apart if you don't have people working to maintain the build environment, automated tests, developer environments. The thing is, a monorepo makes clear what multiple repos can obscure: if you have a software system, then you need all those things anyway. Multiple repos can hide the cost, but they don't eliminate it — in my experience, they multiply it. E.g. if someone makes a breaking change in a monorepo, he breaks the tests and he fixes them before his changes can be merged in; but with multiple repos someone can commit a breaking change and a dependent repo won't know about about it until days, weeks or even months later; the person responsible for fixing it has no idea what really changed or why; and he has a broken build until he does figure it out. > The ability to force updates on dependencies in a single big commit can be really worthwhile as long as you're willing to spend the time to build the tools and do the maintenance. It's like maintaining your car: you can spend $20 to replace your oil every 3,000-5,000 miles, or you can spend thousands every 10,000 miles. Up to you.
- chrishacken 10y ago
  > but with multiple repos someone can commit a breaking change and a dependent repo won't know about about it until days, weeks or even months later; the person responsible for fixing it has no idea what really changed or why; and he has a broken build until he does figure it out. Isn't that the whole point of versioning? If there is a breaking change only the repo's using the latest version will see it. At which point they can submit a bug report before any of that code enters production. I still agree that avoiding all of that is preferred.
  - zellyn 10y ago
    That would be great if people always used versioning correctly. I deal frequently with breaks caused by simple things like renaming, removing, or re-ordering protobuf fields in one repo, and not updating code in another. At least in a monorepo you can catch those sorts of errors.
- slavik81 10y ago
  On the other hand, some of the code you have to update may be for products that have been mothballed. That might end up being a waste of time if the project is never revived. Or the code might be safety-critical and updating it is introducing unnecessary changes (and hence, unnecessary danger). Some tests may include hardware integration. For example, aircraft software may need some number of flight hours after significant changes. That's probably not going to be a part of the CI suite, and the changes will introduce a greater manual testing burden.

fsloth 10y ago

"When it takes hours or more to run tests and produce a build it can really slow the team down. " I don't think those are necessary artifacts of a monorepo. A huge chunk of code does not mean that every component there is connected.

deepsun 10y ago
In Google it is somewhat connected, actually. Sometimes engineers have to run ALL tests over the repo. And it takes hours (better be scheduled overnight!). Although they might have fixed that already.
- deleted 10y ago
  [deleted]
- iamchrisle 10y ago
  Kinda. Depends on who you ask. :)

munificent 10y ago

> a lot of the benefits fall apart if you don't have people working to maintain the build environment, automated tests, developer environments. This is absolutely true. Without a very strong culture around testing and deep, continuous investment in infrastructure and tools, a monolithic repo would quickly devolve to being a giant midden heap of code.

huherto 10y ago
How is that different on multi-repos ? The total amount of code is the same. You also need to keep build environments(not one but several), dependency management is much harder,etc. I would say that any large project needs a "very strong culture around testing and deep, continuous investment in infrastructure and tools"
- Domenic_S 10y ago
  In my experience with small teams, maybe one person will take testing & automation seriously. If they've got a couple small codebases to worry about, it's possible for them to manage. One giant codebase would be too much work. Obviously not the way it should be, etc, but reality bites.
  - tamana 10y ago
    So you've got a few small repos with good build infra,and many small repos that don't. Your overall system is still a sibling ship, and you have no economy of scale force multiplying your few people who take infra seriously
iamchrisle 10y ago
There are dedicated and volunteer teams that work on the internal tools and a strong testing and accountability culture. Everything is built from source.

hvidgaard 10y ago

I still cannot wrap my head around this. What merit does forcing internal code to update a dependancy have? Having dependencies packaged like NuGet, and using an internal repository, you can always remove a particular version of a dependency if you must, and a build will fail if it cannot automatically use the latest minor version.

regularfry 10y ago
It means that I, as a dependency author, can make a breaking change and push not only the updates to my library, but also the updates to all my dependents in a single commit. Using a dependency packaging system like NuGet is a workaround for me not knowing who all my clients are. In a monorepo, I can have perfect knowledge.
- humanrebar 10y ago
  > Using a dependency packaging system like NuGet is a workaround for me not knowing who all my clients are. Between published manifests and search indexed source code, you would know who all your clients are, even without a monorepo.
- michaelt 10y ago
  push not only the updates to my library, but also the updates to all my dependents in a single commit. And what's more, you can run all their automated tests and address any problems your changes introduce. Which presumably means regular forced updates aren't the recipe for instability they would otherwise be.
- gcb0 10y ago
  take debian. you write a new version. push the new package. everyone else's build will fail until they update. its as bad as you describe, but more organized :)
- cwilkes 10y ago
  Should you know who all your clients are? That seems to be a workaround for not having an adequate testing framework or a contract stating what your code will do. Do open source frameworks know everyone's code that is using it? Plus you do have perfect knowledge if your CI tools builds everything on your commit. Which it will do anyway if you have a monorepo.

erikb 10y ago

Agreed. It's a huge dependency of monorepo that is often not spelled out directly. Probably the reason is that the people who successfully implemented monorepos already live so deeply in that continuous integration world, maybe even continuous deployment, so that they don't even know anymore that a huge part of the world has not moved there yet (despite trying for a decade).

wtbob 10y ago

> a lot of the benefits fall apart if you don't have people working to maintain the build environment, automated tests, developer environments. The thing is, a monorepo makes clear what multiple repos can obscure: if you have a software system, then you need all those things anyway. Multiple repos can hide the cost, but they don't eliminate it — in my experience, they multiply it. E.g. if someone makes a breaking change in a monorepo, he breaks the tests and he fixes them before his changes can be merged in; but with multiple repos someone can commit a breaking change and a dependent repo won't know about about it until days, weeks or even months later; the person responsible for fixing it has no idea what really changed or why; and he has a broken build until he does figure it out. > The ability to force updates on dependencies in a single big commit can be really worthwhile as long as you're willing to spend the time to build the tools and do the maintenance. It's like maintaining your car: you can spend $20 to replace your oil every 3,000-5,000 miles, or you can spend thousands every 10,000 miles. Up to you.

chrishacken 10y ago
> but with multiple repos someone can commit a breaking change and a dependent repo won't know about about it until days, weeks or even months later; the person responsible for fixing it has no idea what really changed or why; and he has a broken build until he does figure it out. Isn't that the whole point of versioning? If there is a breaking change only the repo's using the latest version will see it. At which point they can submit a bug report before any of that code enters production. I still agree that avoiding all of that is preferred.
- zellyn 10y ago
  That would be great if people always used versioning correctly. I deal frequently with breaks caused by simple things like renaming, removing, or re-ordering protobuf fields in one repo, and not updating code in another. At least in a monorepo you can catch those sorts of errors.
slavik81 10y ago
On the other hand, some of the code you have to update may be for products that have been mothballed. That might end up being a waste of time if the project is never revived. Or the code might be safety-critical and updating it is introducing unnecessary changes (and hence, unnecessary danger). Some tests may include hardware integration. For example, aircraft software may need some number of flight hours after significant changes. That's probably not going to be a part of the CI suite, and the changes will introduce a greater manual testing burden.