0

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.

Improve this question
7
  • 2
    Do you not trust your employees to not do something that is considered inapropriate?
    – Euphoric
    Commented Jun 29, 2018 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 -
    – Momen Zalabany
    Commented Jun 29, 2018 at 13:00
  • 1
    Then you have bigger issues than monorepo stuff.
    – Euphoric
    Commented Jun 29, 2018 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
    Commented Jun 29, 2018 at 18:35
  • 1
    Possible duplicate of Sharing parts of a monorepo
    – Dan Dascalescu
    Commented Nov 4, 2018 at 11:10

2 Answers 2

Reset to default
8

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

Improve this answer
2
  • 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
    Commented Jun 29, 2018 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
    Commented Nov 4, 2018 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.

Improve this answer
3
  • 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
    Commented Jul 3, 2018 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
    Commented Nov 4, 2018 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
    Commented Nov 4, 2018 at 11:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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