4 ms·

> Sure, if they're actually unrelated, or being managed by separate teams then split it up What if they become managed by separate teams? Or two projects in se

> Sure, if they're actually unrelated, or being managed by separate teams then split it up What if they become managed by separate teams? Or two projects in separate repos become managed by the same team? What about a service that basically everything else in the company relies on (for Google, accounts and auth for example). Better to just keep things in a monorepo IMO, even if they seem unrelated.

dec0dedab0de 4y ago
What if they become managed by separate teams? Or two projects in separate repos become managed by the same team? What about a service that basically everything else in the company relies on (for Google, accounts and auth for example). Better to just keep things in a monorepo IMO, even if they seem unrelated. If there are multiple teams committing to the same repo you need controls over who has permission to commit to which directories and maybe a policy for handling merge conflicts across teams. I'm not sure what the tooling is like around that, but I could see the benefits as long as someone very high up was on board and had enough of a technical mind to keep order. As far as two repos becoming one or one repo becoming two, you can split and merge repos while keeping the commit history. edit: Do you have experience working somewhere with a monorepo that stretched across multiple teams? if so, what was it like?
- thebean11 4y ago
  > As far as two repos becoming one or one repo becoming two, you can split and merge repos while keeping the commit history. I don't have experience doing that but it sounds like a huge headache to me. Any tooling, deployment processes, links in documentation, cross-repo references etc would need to be updated right? The company I was in before my current one used a mono-repo for the whole company, I thought it was pretty great! We had ~150 engineers, so not Google-scale but still many individual teams and services. Similar to the Google strategy, a pull request / code review would be against master, and then it would be merged directly to master. The tooling would automatically rebase your change on master before merging. Deployment would happen automatically or manually (the team could decide) and would be pinned to a git commit hash. If automatic, the CI tool would detect if there were any changes to your binary that required deployment (so a totally unrelated PR would not trigger a deploy). You could manually deploy an older commit hash if you wanted.

dec0dedab0de 4y ago

What if they become managed by separate teams? Or two projects in separate repos become managed by the same team? What about a service that basically everything else in the company relies on (for Google, accounts and auth for example). Better to just keep things in a monorepo IMO, even if they seem unrelated. If there are multiple teams committing to the same repo you need controls over who has permission to commit to which directories and maybe a policy for handling merge conflicts across teams. I'm not sure what the tooling is like around that, but I could see the benefits as long as someone very high up was on board and had enough of a technical mind to keep order. As far as two repos becoming one or one repo becoming two, you can split and merge repos while keeping the commit history. edit: Do you have experience working somewhere with a monorepo that stretched across multiple teams? if so, what was it like?

thebean11 4y ago
> As far as two repos becoming one or one repo becoming two, you can split and merge repos while keeping the commit history. I don't have experience doing that but it sounds like a huge headache to me. Any tooling, deployment processes, links in documentation, cross-repo references etc would need to be updated right? The company I was in before my current one used a mono-repo for the whole company, I thought it was pretty great! We had ~150 engineers, so not Google-scale but still many individual teams and services. Similar to the Google strategy, a pull request / code review would be against master, and then it would be merged directly to master. The tooling would automatically rebase your change on master before merging. Deployment would happen automatically or manually (the team could decide) and would be pinned to a git commit hash. If automatic, the CI tool would detect if there were any changes to your binary that required deployment (so a totally unrelated PR would not trigger a deploy). You could manually deploy an older commit hash if you wanted.