2

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.

  • 2
    Do you not trust your employees to not do something that is considered inapropriate? – Euphoric Jun 29 '18 at 6:01
  • @Euphoric i like to respect speciality, and avoid a team waking up to see an unexpected behaviour 5hat no one know about just to run blame and find out it was done by another team that may not even hv design docs of project -happened in real frontend edited api response to make his life easier without consulting backend team - – Zalaboza Jun 29 '18 at 13:00
  • 1
    Then you have bigger issues than monorepo stuff. – Euphoric Jun 29 '18 at 13:15
  • Sounds like you have an either/or problem. Either you have one repo with everything in it, or you have separate repos based on the product. You can control dependencies with good package management that supports versioned dependencies. – Berin Loritsch Jun 29 '18 at 18:35
  • 1
    Possible duplicate of Sharing parts of a monorepo – Dan Dascalescu Nov 4 '18 at 11:10
6

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.)

  • This. I’ve read somewhere that the Angular team is responsible for fixing every client in the repository if they make a breaking change. – RubberDuck Jun 29 '18 at 21:34
  • "Team A" and "Team B" is a misleading situation, because it implies that both teams work for the same company and could be trusted. The real problem is if "Team B" is a contractor hired to work only on a very specific project from the monorepo, say the design of some web pages. – Dan Dascalescu Nov 4 '18 at 11:08
2

I would consider a system of requiring reviews from specific people based on the files changed.

For instance, code that touches /service-a requires a review from a member of the team that is primarily responsible for that service. This way, engineers outside of the Service A team are still enabled to interact with Service A's source code but can't merge without approval from that team.

  • 1
    This is a great suggestion. Some tools like GitHub support a CODEOWNERS file that can enforce this process: you can specify code owners on a per-directory basis which must approve any change within that directory before it can be merged. – amon Jul 3 '18 at 20:51
  • @amon: approving changes does nothing to prevent an external contractor hired to work only on a specific project of the monorepo, from stealing the entire code base. If "Team B" is that contractor, we have a real problem. – Dan Dascalescu Nov 4 '18 at 11:10
  • @DanDascalescu OP's comments suggests they are concerned about managing changes to the code base, not so much about keeping code secret from external contractors. You're technically right to mention that issue, though spamming it three times on this question is a tad excessive. – amon Nov 4 '18 at 11:55

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.