Monorepo vs Multirepo

https://semaphoreci.com/blog/what-is-monorepo

What is monorepo? (and should you use it?) - Semaphore

 

우선 대형 모노레포를 운영하는 회사로 Google, MS, Facebook, Twitter가 잘 알려져있다.

 

Monorepo

 : 다양한 project들을 하나의 repository에서 통합하여 관리

 

Multirepo

 : 각각의 project들을 각각의 repository에서 관리

 

 

Monorepo에 이점

- Visibility(가시성) : 모두가 다른이들이 코드를 볼 수 있다. 이 이점은 협업과 팀기여로 이끈다. - 어떤 개발자는 존재하지도 몰랐던 레포의 버그를 픽스 할 수 있게 된다.

 

- Simpler dependency management: 패키지 관리자가 필요하지 않는다...? 모든 모듈이 한 레포에 호스팅 되기 때문에

 

- Single source of truth: 단 하나의 단일 소스는 버전 충돌을 야기하지 않는데;;

 

- Consistency: 코드 퀄리티 스탠다드와 통합된 스타일을 쉽게 관리할 수 있다.

 

- Shared timeline: breaking change나 shard libraries가 업데이트 됨으로써 협력하고 있는 다른 팀에게 바로 노출되므로 좀 더 현상을 유지하기 위해 모두가 노력한다.

 

- Atomic commits: atomic commit을 통해 큰 규모의 리팩토링을 쉽게 할 수 있다가 왜 이점일까? 모노레포의 이점이 아니지않나..?

 

- Implicit CI: 이미 통합이 되어있어 지속적이 통합 노력이 덜 듬

 

- Unified CI/CD: 모두 같은 레포에있어 같은 process를 모든 project의 적용하기 좋음

 

- Unified build process: 통합된 빌드프로세스

 

단점

 

- Bad performance: git blame처럼 누가 코드 수정했는지에 대한 command가 느려질 수 있음

 

- Broken main/master: main branch가 망가짐으로써 같은 레포에서 일하는 모두에게 영향이 확대됨

 

- Learning curve: 특정한 프로젝트가 타이트하게 관리된다면 신규개발자에게 러닝커브가 클수가 있음

 

- Large volumes of data: 모노레포가 하루에 감당하기 힘든 양의 commit data에 도달할 수 있다.

 

 

 

https://turborepo.org/docs/handbook/what-is-a-monorepo

polyrepo

- multiple codebase which are published and veersione separately

 

In a polyrepo

In a polyrepo setup, the process for sharing code between applications is relatively lengthy.

Imagine that you have three separate repositories - app, docs, and shared-utils. Both app and docs depend on shared-utils, which is published as a package on npm.

Let's say a bug in shared-utils is causing a critical issue in both app and docs. You'll need to:

1. Make a commit in shared-utils fixing the error
2. Run a publish task inside shared-utils to publish it to npm
3. Make a commit in app bumping the version of the shared-utils dependency
4. Make a commit in docs bumping the version of the shared-utils dependency
5. app and docs are now ready to be deployed.

The more apps you have that depend on shared-utils, the longer this process takes. It can be extremely arduous.