4 ms·
> 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
by 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 agoThat 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 agoOn 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.
- tamana 10y agoThat's why you delete dead code at head (keeping archive of history) , and you have dev branches and release branches