There are lots of advantages to a monorepo. We also read that large companies like Google and Facebook use this tech to keep all source code in a single repo.
But how do you manage to limit access of a certain team to projects they are working on when using a monorepo?
For example, we have a microservice infrastructure:
- Service A
- Service B
- Api Gateway
Service A is developed using Team A, and service B is developed by Team B, while Api Gateway is the common repo in this project.
How can we limit access of each team to its own service only?
Currently we keep every part in its own repo, and this way we can control access for each team. But I was asked to migrate this to monorepo, and I am not sure how to protect source code and split the project with such an approach.
Best Answer
You don't want to.
The whole point of a monorepo is that every developer can touch all the code. That way, all the projects, subprojects, and libraries can be kept "in sync" across the whole code base, so that you don't get into "version dependency hell", etc.
Example:
Team Service-B needs to do some restructuring on a common library in the monorepo, which will break code in API-Gateway and Service-B.
Team B will do the whole restructuring process, including fixing up code of A and API and making sure all Test Suites run. (Team B will likely check back with the other teams first; may get some support from the others, if things get hairy, of course.)
Once all Test Suites run and everything is green, Team B checks in the new, one-and-only, state of the monorepo.
Disclaimer: We do have a monorepo of sorts. As it continues to grow, I'm not convinced it's all the happy path some people seem to think. Especially without heavy tooling and good Test Suites, it becomes brittle quickly, IMHO.
Titus Winters of Google does some explaining in CppCon 2017: Titus Winters “C++ as a "Live at Head" Language”. (Least I think it was this video where he explains the monorepo approach.)