4 ms·

Regardless of how you're deploying things, having unrelated projects in the same git repository might be simpler (maybe?) but certainly seems worse at the same

Regardless of how you're deploying things, having unrelated projects in the same git repository might be simpler (maybe?) but certainly seems worse at the same time. Sure, if they're actually unrelated, or being managed by separate teams then split it up. Though I think the default should be to have one, and split it when there is an actual reason to, especially if it's for the same project. The example I gave wasn't an exaggeration, 14 repos for one project. It was originally built and managed by one person who had them all in the same directory and would open them all in his IDE at once and basically worked on it as a mono repo. After that person quit, when others needed to figure out which repo to clone to fix things it was a nightmare. I know monorepos can be extreme like google, but I just mean one per team, or at least one per project. You shouldn't have to worry about versions of your libraries when there is only one project using those libraries. Edit: For example, a project I did the layout for has a python backend, with a spa frontend, and some ansible playbooks for deployment, integration tests, and a few libraries only used by this project. Each of those 5 things has a top level directory and we deploy a test server for every branch, plus most of us run a local server. We never have to worry about versioning between our own projects, because if they're in the same branch that's the version to use. If we split it into separate repos, then everytime we added a new field to the api, and needed to update the frontend and tests, we would have to manually specify which versions of all the repos go together to build a test server, or to even run a local dev server.

ushakov 4y ago
i'm wondering what engineering decisions drove the project to be split in 14 parts? is it like micro-services thing or what?
- dec0dedab0de 4y ago
  Yes it was mostly micro services, with a separate frontend repo, and a separate repo for deploy scripts, some separate libraries that were shared between the microservices, there may have even been a separate repo for documentation, I don't remember exactly. I think it really just came down to dividing the repos into chunks that the deployment scripts could use/trigger off of. Instead of developing in a way that makes sense for developers and bending the deployment to fit. Since it was all in one directory on his computer, it was basically a mono repo from his perspective. Committing from the IDE just committed to whichever repo was changed, and since he was the only developer he never saw the downside. When I had to take it over ghorg[0] really came in handy. It's a script to clone all repos from a user/organization on gitlab, github, and others. Then once I opened up all the repos as one pycharm project I was able to get some stuff done, but at that point I might as well just had one repo with a separate directory for each. [0]https://github.com/gabrie30/ghorg https://github.com/gabrie30/ghorg EDIT: I also just remembered that gitlab is much better than github if you are going to go the route of multiple repos for one project. Gitlab lets you create namespaces to group your repos, so if they're all in the same namespace, you could have documentation to just tell people to clone all of them.
thebean11 4y ago
> 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.

ushakov 4y ago

i'm wondering what engineering decisions drove the project to be split in 14 parts? is it like micro-services thing or what?

dec0dedab0de 4y ago
Yes it was mostly micro services, with a separate frontend repo, and a separate repo for deploy scripts, some separate libraries that were shared between the microservices, there may have even been a separate repo for documentation, I don't remember exactly. I think it really just came down to dividing the repos into chunks that the deployment scripts could use/trigger off of. Instead of developing in a way that makes sense for developers and bending the deployment to fit. Since it was all in one directory on his computer, it was basically a mono repo from his perspective. Committing from the IDE just committed to whichever repo was changed, and since he was the only developer he never saw the downside. When I had to take it over ghorg[0] really came in handy. It's a script to clone all repos from a user/organization on gitlab, github, and others. Then once I opened up all the repos as one pycharm project I was able to get some stuff done, but at that point I might as well just had one repo with a separate directory for each. [0]https://github.com/gabrie30/ghorg https://github.com/gabrie30/ghorg EDIT: I also just remembered that gitlab is much better than github if you are going to go the route of multiple repos for one project. Gitlab lets you create namespaces to group your repos, so if they're all in the same namespace, you could have documentation to just tell people to clone all of them.

thebean11 4y ago

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