Monorepo Support

I am convinced that the monorepo (a single repository to store code for all of the organization's microservices) is something google concocted to keep their 250+ infra and devops engineers very busy.

At Amazon, a small team of just 5 people might own around 100 repos. But they have tooling that makes that easier to organize and manage. Google has a ridiculous amount of code in a single repo, but they too have specialized tooling that makes that manageable.

Since you laid out the case for monorepos, I'll share some points about why one might prefer multirepo. These points mainly center around microservices, since you probably are monorepo by default if you have a monolith:

1. Tooling is more straight-forward for it out of the box. For a given service, create a repo from a template and you're live. You don't need to derp around with lerna or yarn workspaces and figure out how to make those work when some repos use maven or rubygems and cocoapods in addition to npm.

2. Better enforcement of requiring services to only communicate over API boundaries instead of code-share. Monorepos make violation of service boundaries too easy.

3. If you're doing a monolith, monorepos may be fine, but there are a ton of problems you run into if you use them for microservices. If you have one mega pipeline for all services, what happens if a single service fails to deploy or fails post-deployment CI checks? If you have multiple pipelines, what do you do when 4/12 pipelines fail? How do you track which commit each service is at in different stages? What happens if CI checks end up failing for some other service than the one you actually touched on your PR submission?

4. Less merge-conflict/out of date branch noise when developing.

5. Able to see which commits, PRs, issues, etc are associated with which service without needing to setup manual labor or build tooling to auto-label and tagging.

6. Possible to introduce fine-grained permissions on different repos/sections of the code. You can limit view permissions of top-secret projects, grant teams more ownership of their own repos, etc.

7. Fine-grained permissioning extends to automated tools. If you install a Github app to only one repo, it's limited to what it can do. This is a blast radius reduction you get only with multi-repo. With a mono-repo, you also have all Github secrets shared with the whole repo. If only one service should have access to certain secrets, you can't model that.

8. If you use git tags for service release annotations, it'd get very noisy to have tags for every service all in one monorepo.

9. If you want to generate automated release notes on deployment or library package publication, where can that go in a monorepo? The Github releases API gives you that for free, but if you're doing a monorepo without a monolith, you're going to have to find or build your own tooling here.

- CI/CD that runs on the entire thing

- merge policy that requires branch being up-to-date even for FF merges

  - I once spent an entire day trying to merge a PR because CI for other people changes was taking N minutes, but mine was N + 1 minutes. I kid you not, I resigned a week after that day because I just couldn't.

 - Messy organization within the repo

 - People wanted tag releases, so every single service within monorepo was on the same version and some of had months since last activity

 - Whole kitchen sink in one repo: terraform, Ansible, source code, fucking debian packages, secrets (sop) whatever else VPoE thinks is part of engineering.

 - include over an include in pipeline files (this was GitLab CI) that is impossible to navigate because of name collisions.

We are treating it as an experiment. Got 2 teams with 5/6 Devs in each sharing the same monorepo. We are using nx.dev as the build tool and it's going pretty well so far.

Different tech stacks too but using nx.dev thats been abstracted away. Allows us to share practices and we've built out the CI/CD and supporting infrastructure on AWS together which has certainly saved duplication of effort. Possibly one more team coming on board too.

If in the future it's not paying off we can always split. Doesn't need to be a forever decision, is how we are viewing it.