Monorepos

Most development shops with multiple departments, software packages, or teams will gravitate towards having separate repositories for their various bits of code. If they have to share code, they stand up a server someone to serve up things like nuget and npm packages for whatever system happens to need them. This works great, as long as those separate pieces of code don’t need any sort of integration. However, this isn’t likely for many environments. After all, unless you are doing contract development work for other companies, those disparate pieces of code that you have scattered across multiple repositories are probably going to have to work together at some point. Once this happens, all kinds of other issues come up. Teams don’t understand each other’s code, release timings now have to be coordinated, you get weird regressions from tiny library updates, you have difficulty testing, and deployment requires orchestration. Plus, it tends to lead to communication problems and political nonsense over time. After running into this, you’ve probably also read about other organizations who put all their code in a single repository. It sounds like something that might help, but will it? Like anything else, there are always downsides. And like most things, at least half the downsides that can happen are things that didn’t immediately come to mind when you considered the idea. Monorepos can ease a lot of the pain associated with development in organizations with multiple repositories, but they aren’t always the best choice. Further, even in cases where they are a good choice, there are things you need to figure out before migration – you can’t just dump everything into the same repository and turn it loose. You have to plan ahead and carefully consider what benefits they provide along with the challenges that might occur. There is no silver bullet. Links Join Us On Patreon Level Up Financial Planning Donate to Beej’s Mission Fund Memo: Put “BJ Burns” in Memo