우리는 하나다! 모노레포 with pnpm

https://www.youtube.com/watch?v=Bycg5w5qXfE

이전- 모놀리식 애플리케이션

모듈화 없이 설계된 소프트웨어 어플리케이션
아키텍쳐 빠르게 개발 가능
but 관심사의 분리가 제대로 되지 않는 문제

한계점 극복 - 모듈식 애플리케이션

동일한 관심사 별로 분리하여 그들만의 인터페이스 정의
각 모듈들을 다른 어플리케이션에서도 사용한다면?
- 모듈을 다른레포지토리에 분리해서 별도로 배포해서.. like 라이브러리..

모노레포 등장배경 (멀티레포 - 폴리레포)

각 모듈은 독립적인 개발환경, 배포파이프라인을 가지게 된다.
높은 자율도
프로젝트별로 독립된 레포지토리를 쓰는거를 멀티레포라고 하고, 대부분의 개발팀에서 채택중이다.
코드 작성부터 배포를 모두 다 독립적으로 구성할 수 있어서 좋다.

문제점

반복되는 배포 파이프라인, 개발환경 계속해서 따로 관리해줘야함
한 레포에서 타사 라이브러리 버전 의존에서 따른 호환성 이슈
연관된 레포의 변경점을 바로바로 파악하지 않으면 문제가 생긴다.
높은 자�율성으로 인해 일관되지 않은 개발자 경험

이런 문제점을 해결하기 위해 모노레포 등장

모노레포란, 다수의 서비스를 하나의 레포지토리에서 관리하는 전략
독립된 레포지토리 형태로 존재하던 멀티 레포들을, 프로젝트 단위로 모두 가져와서 의존성 관리가 쉬워서 �관리 포인트 단일화

모노레포 장점

여러 �프로젝트 간의 코드의 공유와 재사용이 쉽다.
모노레포 내 프로젝트를 담당 개발자 간 협업이 쉽다.
- 일관된 도구 제공, 프로젝트마다 동일한 코드 컨벤션
- 단일 레포지토리에서 함께 작업
통합된 개발환경 및 Devops 구성
새 프로젝트를 손쉽게 만들 수 있다.

모노레포 단점

의존성 연결이 쉬운 만큼 필요 이상의 과도한 의존 관계가 나타날 수 있다.
하나의 CI 를 구성하기 위한 어려움
- 분산 작업 실행
- 빌드 혹은 테스트 로컬 캐싱
모든 코드가 밀집되어 있어 작은 문제가 큰 문제로 확산 될 가능성이 있다.
- 구글 모노레포의 경우 코드가 20억줄에 달하여 매일 4만 5천건의 커밋을적용..

생각

예전에 lerna 로 모노레포 구성하려다가 이것저것 꼬여서 못했었는데 다시 해봐야겠다.
특히 레포지토리끼리 interface 공유할 때 정말 좋을거라구 생각했음. 물론 다른 코드 공유하기 쉽겠지만.. Interface의 경우 설계 전반을 책임지는 부분이어서.