4 ms·

Thanks for the insights. > E.g. fixing log4j vulns is a lot easier when you can patch everything simultaneously. This is true, though the refactoring action d

by hrpnk 4y ago

Thanks for the insights. > E.g. fixing log4j vulns is a lot easier when you can patch everything simultaneously. This is true, though the refactoring action done can also be distributed and carried out via automated Pull Request creation to multiple repos. You still will deploy the changes over a period of time with a degree of parallelism. > We had microrepos before and the main problem is that to this day I still get some random team coming to me for help w/ some rediscovered 7 year old repo that doesn't even build anymore cus lockfiles weren't a thing back then. You can solve this by forcing a CI build for every repo to be run periodically. > For us and companies like Google, monorepos work well with our organization model. What are the concrete aspects of the organization model that make both orgs favor monorepos?

lhorie 4y ago
Upgrades come in a spectrum. Some are able to automerge via dependabot or similar tools, some need minor codemodding and can be managed by tools like soucegraph's new offering. Some take months of dedicated effort and digging through the ripple effects across a web of ecosystem libraries (React comes to mind). The problem monorepos attempt to solve isn't a technology problem, it's more of a people problem. For example, say you cron CI job fails. Then what? Someone needs to look at it. It's easier for someone to fix things they currently have context for (e.g. if I upgrade Python or update some security-related config and something breaks, I can reason it was my change that broke it), vs an unsuspecting contractor getting around to some backlog task 6 months after the fact with no context. Organizationally, we can shard tasks to match areas of expertise. We only need one Node.js expert, one tzdata expert, one JRE expert, etc, to upgrade each of these, instead of everyone needing to obtain above average familiarity w/ obscure FFI bullshit or whatever in each technology.

by hrpnk 4y ago

lhorie 4y ago

Upgrades come in a spectrum. Some are able to automerge via dependabot or similar tools, some need minor codemodding and can be managed by tools like soucegraph's new offering. Some take months of dedicated effort and digging through the ripple effects across a web of ecosystem libraries (React comes to mind). The problem monorepos attempt to solve isn't a technology problem, it's more of a people problem. For example, say you cron CI job fails. Then what? Someone needs to look at it. It's easier for someone to fix things they currently have context for (e.g. if I upgrade Python or update some security-related config and something breaks, I can reason it was my change that broke it), vs an unsuspecting contractor getting around to some backlog task 6 months after the fact with no context. Organizationally, we can shard tasks to match areas of expertise. We only need one Node.js expert, one tzdata expert, one JRE expert, etc, to upgrade each of these, instead of everyone needing to obtain above average familiarity w/ obscure FFI bullshit or whatever in each technology.