4 ms·

No offense but I think you're doing monorepos wrong. We have more than 100 applications living in our monorepo. They share common core code, some common signals

No offense but I think you're doing monorepos wrong. We have more than 100 applications living in our monorepo. They share common core code, some common signals, common utility libs, and all of them share the same build. We release everything weekly, and some things much more frequently. If your testing is good enough, I don't see what the issue is?

bluGill 2y ago
> If your testing is good enough, I don't see what the issue is? Your testing isn't good enough. I don't know who you are, what you are working on, or how much testing you do, but I will state with confidence it isn't good enough. It might be acceptable for your current needs, but you will have bugs that escape testing - often intentional as you can't stop forever to fix all known bugs. In turn that means if anything changes in your current needs you will run into issues. > We release everything weekly, and some things much more frequently. This is a negative to users. When you think you will release again next so who cares about bugs it means your users see more bugs. Sure it is nice that you don't have to break open years old code anymore, but if the new stuff doesn't have anything the user wants is this really a good thing?
- munksbeer 2y ago
  > Your testing isn't good enough. I don't know who you are, what you are working on, or how much testing you do, but I will state with confidence it isn't good enough. Yes, that is true. No amount of testing can prevent bugs in a complex enough project. But this is no different in a monorepo or multirepo. I apologise but I don't think I've understood your point.
  - bluGill 2y ago
    My point is that releasing weekly because your testing is good enough is not possible. It might be an acceptable compromise for your problem, but there are others who that isn't enough. I work on software that is safety critical, as such we require all releases to go through several weeks of manual testing - this is after a very large automated test suite. Realistically it is months of manual testing, but if programmers were perfect it could be done in weeks.
    - munksbeer 2y ago
      Ok, but how does that relate to the original point about monorepos?
      - bluGill 2y ago
        Your point about mono repos and your point about testing have no relation to each other as far as I can see.
memsom 2y ago
No offence, but you might be a little confused by how complex your actual delivery is. That sounds simple. That sounds like it has a clear roadmap. When you don’t, and you have very agile development that pivots quickly and demands a lot of change concurrently for releases that have very different goals, it is not possible to make all your ducks sit in a row. Monorepos suck in that situation. The dependency graph is so complex it will make your head hurt. And all the streams need to converge in to the main dev branch at some point, which causes huge bottlenecks.
- tomtheelder 2y ago
  The dependency graph is no different for a monorepo vs a polyrepo. It's just a question of how those dependencies get resolved.
  - memsom 2y ago
    With multiple repos, we can get a single deliverable for each project requirement, manage convergence and still maintain a main branch for each repo. The artifacts can be packaged and consumed by the other dependencies that are changing. It stops monolithic development. It library A needs to branches of change, we don’t need to create 2 branches for the entire product line. You literally only change the parts you are currently working on, and insignificant changes don’t get sucked in by proxy.

bluGill 2y ago

> If your testing is good enough, I don't see what the issue is? Your testing isn't good enough. I don't know who you are, what you are working on, or how much testing you do, but I will state with confidence it isn't good enough. It might be acceptable for your current needs, but you will have bugs that escape testing - often intentional as you can't stop forever to fix all known bugs. In turn that means if anything changes in your current needs you will run into issues. > We release everything weekly, and some things much more frequently. This is a negative to users. When you think you will release again next so who cares about bugs it means your users see more bugs. Sure it is nice that you don't have to break open years old code anymore, but if the new stuff doesn't have anything the user wants is this really a good thing?

munksbeer 2y ago
> Your testing isn't good enough. I don't know who you are, what you are working on, or how much testing you do, but I will state with confidence it isn't good enough. Yes, that is true. No amount of testing can prevent bugs in a complex enough project. But this is no different in a monorepo or multirepo. I apologise but I don't think I've understood your point.
- bluGill 2y ago
  My point is that releasing weekly because your testing is good enough is not possible. It might be an acceptable compromise for your problem, but there are others who that isn't enough. I work on software that is safety critical, as such we require all releases to go through several weeks of manual testing - this is after a very large automated test suite. Realistically it is months of manual testing, but if programmers were perfect it could be done in weeks.
  - munksbeer 2y ago
    Ok, but how does that relate to the original point about monorepos?
    - bluGill 2y ago
      Your point about mono repos and your point about testing have no relation to each other as far as I can see.

memsom 2y ago

No offence, but you might be a little confused by how complex your actual delivery is. That sounds simple. That sounds like it has a clear roadmap. When you don’t, and you have very agile development that pivots quickly and demands a lot of change concurrently for releases that have very different goals, it is not possible to make all your ducks sit in a row. Monorepos suck in that situation. The dependency graph is so complex it will make your head hurt. And all the streams need to converge in to the main dev branch at some point, which causes huge bottlenecks.

tomtheelder 2y ago
The dependency graph is no different for a monorepo vs a polyrepo. It's just a question of how those dependencies get resolved.
- memsom 2y ago
  With multiple repos, we can get a single deliverable for each project requirement, manage convergence and still maintain a main branch for each repo. The artifacts can be packaged and consumed by the other dependencies that are changing. It stops monolithic development. It library A needs to branches of change, we don’t need to create 2 branches for the entire product line. You literally only change the parts you are currently working on, and insignificant changes don’t get sucked in by proxy.