I'm in need of some advice before going foward.
I want to build several large scale projects, like a marketplace product, and a few domain-specific products and libraries. The products may or may not be related but may share libraries. Each product may very well be their own companies [e.g. the marketplace]).
I'm for using monorepos. There are as many benefits as there are disadvantages. Pro-monorepo points are discussed in Advantages of monolithic version control at danluu.com and in the associated links in the article.
Why I think I need a monorepo — I've read about the pros of monorepo, but I'm mainly focused on following:
- Sharing closed-source code. The products and projects will share internal (closed-source) libraries. Code sharing becomes simpler because closed-source dependencies are locally available. Project-based repositories require proper tooling for building. I'm trying to avoid this requirement since I'm unable to find any tools for managing closed-source dependencies using multiple repos.
Why monorepos will be a problem
- Inability to scale.
- Inability to rollback changes without major problems.
- Inability to hide sensitive code. Because products and projects share a single repo, code from one product will be exposed.
Questions
- What's the best practice for managing several closed-source large-scale projects in a monorepo?
- Would it be wise (and sane) to have these large-scale projects in the same repo?
Thanks guys
Best Answer
To manage large scale complexity, the winning principle since Julius Caesar is "Divide et impera", in English divide and rule (or divide and conquer). This principle applies to political empires as well as software empires.
Software Engineers do not intend to conquer empires, so they call this differently. The main variants of this principle are separation of concerns, componentisation and encapsulation (in the sense of information hiding, that is hiding the internals of a component). All these principles are based on the fact that it is easier to build independent loosely coupled parts and when needed, assemble the black boxes to achieve higher value without getting lost in details and unexpected interactions and dependencies.
Adopting several independent repos allows you to empower the different participating teams to use the procedures that best fit their needs, to manage different release schedules, and -- why not -- open source, sell or subcontract the different components to leverage efficiency (e.g. open source a more general library but still keep control on your other more specific products).
All this (and in addition the many other challenges related to the monolith) certainly explains why monorepos are nowadays more the exception than the rule. I'd strongly advise you to reconsider your choice.