Mono-repo와 Multi-repo는 Git을 통해 코드를 호스팅하고 관리하기 위한 두 가지 주요 전략입니다. 우리는 전략과 장단점에 대해 자세히 논의합니다.
목차
소개
최신 프로젝트의 대부분은 Git에서 관리 및 호스팅됩니다. Git은 분산 소스 코드 관리, 버전 제어 및 전 세계 어디에서나 협업을 위한 표준 플랫폼이 되었습니다. Git은 빠르고 효율적입니다. Git 코드를 호스팅하고 관리하는 두 가지 주요 접근 방식이 있습니다.
이러한 접근 방식을 살펴보기 전에 repo가 어떻게 작동하는지 이해합시다.
리포지토리는 무엇입니까?
리포지토리(Repo)에는 프로젝트의 모든 폴더와 파일이 포함됩니다. 여기에는 사용자, 사람 및 컴퓨터에 대한 정보도 포함됩니다.
리포지토리 데이터는 버전 제어됩니다. 저장소는 개인 또는 팀 구성원 그룹이 소유할 수 있습니다.
Git은 저장소입니다. 공개, 비공개 또는 내부일 수 있습니다. GitHub는 Git 저장소의 호스팅 서비스이며 사용자 인터페이스가 있습니다.
Git은 버전 제어 및 코드 공유 기능을 제공하지만 Git이 다른 점은 개발자가 파일을 일부 변경하려는 경우 전체 저장소를 로컬 시스템에 복사할 수 있다는 것입니다. 따라서 개발자가 특정 프로젝트에 대한 쓰기 권한이 없더라도 콘텐츠를 로컬로 복사하고 수정할 수 있습니다(포킹이라고 함).
또한 개발자가 로컬에서 변경한 내용을 공유하려는 경우 프로젝트 소유자에게 “풀 리퀘스트”를 보낼 수 있습니다.
프로젝트는 단일 서비스를 가질 수 있습니다. 프로젝트에 여러 워크플로가 있는 경우 각 워크플로에 대해 여러 서비스를 만들 수 있습니다. 대부분의 개발자는 더 큰 프로젝트를 하나 이상의 기능이 있는 더 작은 독립 서비스로 분할하는 것을 선호합니다. 각 서비스는 다양한 비즈니스 문제를 해결할 수 있습니다. 서버리스 프레임워크의 대중화로 사용자는 기능에 서비스로 액세스할 수 있습니다.
이러한 기능을 서비스로 생성하고 배포한 후 다음 단계는 기능을 구조화하고 버전을 제어하는 것입니다. 모든 서비스를 하나의 저장소(모노 저장소)에 포함하거나 보유하고 있는 각 서비스에 대해 별도의 저장소를 가질 수 있습니다( 다중 리포지토리)!
모노레포란?
모노 리포지토리 접근 방식에서는 모든 서비스를 단일(모노) 리포지토리에 보관할 수 있습니다. 여전히 각 서비스를 독립적으로 배포하고 관리할 수 있습니다. 서비스는 공통 라이브러리와 코드를 공유할 수 있습니다.
Facebook, Google 및 Dropbox와 같은 회사는 모노 레포를 사용합니다.
모노레포의 장점
Mono-repo 접근 방식에는 다음과 같은 많은 장점이 있습니다.
- 모든 프로젝트 코드를 저장하고 팀의 모든 사람이 액세스할 수 있는 단일 장소
- 코드 재사용 및 공유 용이, 팀과의 협업
- 변경 사항이 전체 프로젝트에 미치는 영향을 쉽게 이해할 수 있습니다.
- 코드 리팩토링 및 코드에 대한 대규모 변경을 위한 최상의 옵션
- 팀 구성원은 전체 프로젝트를 전체적으로 볼 수 있습니다.
- 종속성을 관리하기 쉽습니다.
모노레포의 단점
물론 mono-repo에는 몇 가지 단점이 있으며 주요 단점은 성능입니다. 프로젝트가 커지고 더 많은 파일이 격일로 추가되는 경우 체크아웃, 가져오기 및 기타 작업이 느려지고 파일 검색이 더 오래 걸릴 수 있습니다.
또한 프로젝트를 위해 많은 독립 계약자를 고용하는 경우 전체 코드 기반에 대한 액세스 권한을 부여하는 것이 안전하지 않을 수 있습니다.
또한 많은 사람들이 변경 사항을 체크인할 수 있고 CI(지속적 통합) 시스템이 여러 번 재구축해야 하기 때문에 CD(지속적 배포)를 구현하기 어렵습니다.
단일 리포지토리를 사용하는 대기업에는 확장 문제를 처리하기 위한 맞춤형 도구가 있습니다. 예를 들어 Facebook은 사용자 지정 파일 시스템과 소스 제어를 사용합니다.
멀티 리포지토리란 무엇입니까?
다중 리포지토리 접근 방식에는 프로젝트의 여러 라이브러리 및 서비스를 호스팅하는 여러 리포지토리가 있습니다. 서비스가 변경되면 개발자는 전체 프로젝트가 아닌 해당 서비스만 다시 빌드해야 합니다. 개인과 팀은 특정 서비스에 대해 작업할 수 있으며 필요한 서비스에만 액세스할 수 있습니다.
Netflix 및 Amazon과 같은 회사는 다중 리포지토리를 사용합니다.
멀티 리포지토리의 장점
다중 리포지토리를 채택하는 회사의 수는 다음과 같은 이유로 모노 리포지토리를 채택하는 회사보다 훨씬 많습니다.
- 각 서비스와 라이브러리에는 고유한 버전 관리가 있습니다.
- 코드 체크아웃 및 풀링이 작고 분리되어 프로젝트 규모가 커져도 성능 문제가 없습니다.
- 팀은 독립적으로 작업할 수 있으며 전체 코드베이스에 액세스할 필요가 없습니다.
- 더 빠른 개발 및 유연성
- 각 서비스는 개별적으로 출시될 수 있고 자체 배포 주기가 있으므로 CI 및 CD를 더 쉽게 구현할 수 있습니다.
- 더 나은 액세스 제어 – 모든 팀이 모든 라이브러리에 대한 전체 액세스 권한을 가질 필요는 없지만 필요한 경우 읽기 액세스 권한을 얻을 수 있습니다.
다중 리포지토리의 단점
- 최신 버전을 얻으려면 서비스와 프로젝트에서 사용되는 종속성과 라이브러리를 정기적으로 동기화해야 합니다.
- 어느 시점에서 사일로 문화를 장려하여 코드가 중복되고 개별 팀이 동일한 문제를 해결하려고 합니다.
- 각 팀은 코드에 대해 서로 다른 모범 사례 집합을 따를 수 있으므로 일반적인 모범 사례를 따르는 데 어려움이 있습니다.
모노 리포지토리와 멀티 리포지토리의 차이점
모노 리포지토리와 멀티 리포지토리의 차이점을 요약해 보겠습니다.
모노레포
다중 리포지토리
조직의 모든 프로젝트의 모든 코드는 중앙 저장소에 있습니다.
각 서비스와 프로젝트에는 별도의 저장소가 있습니다.
팀은 협업하고 함께 작업할 수 있습니다. 그들은 서로의 변화를 볼 수 있습니다
팀은 자율적으로 작업할 수 있습니다. 개별 변경 사항은 다른 팀이나 프로젝트의 변경 사항에 영향을 미치지 않습니다.
각 사람은 전체 프로젝트 구조에 액세스할 수 있습니다.
관리자는 개발자가 액세스해야 하는 프로젝트 또는 서비스에 대한 액세스 제어를 제한할 수 있습니다.
프로젝트 규모가 계속 커지면 스케일업 문제가 발생할 수 있습니다.
제한된 코드와 더 작은 서비스 단위로 인해 우수한 성능
CD(지속적 배포) 및 CI(지속적 통합) 구현의 어려움
개발자는 독립적으로 서비스를 구축할 수 있으므로 CD 및 CI를 쉽게 얻을 수 있습니다.
개발자는 중앙 저장소에서 업데이트되는 라이브러리, API 및 기타 공통 코드를 쉽게 공유할 수 있습니다.
라이브러리 및 기타 공통 코드에 대한 변경 사항은 나중에 문제가 발생하지 않도록 주기적으로 동기화해야 합니다.
결론
모노 리포지토리와 다중 리포지토리는 모두 똑같이 인기가 있으며 어느 것이 더 나은지는 프로젝트 크기, 프로젝트 요구 사항, 필요한 버전 관리 및 액세스 제어 수준에 따라 다릅니다.
Mono-repo는 일관성을 선호하는 반면 multi-repo는 디커플링에 중점을 둡니다. 단일 리포지토리에서는 전체 팀이 한 사람이 수행한 변경 사항을 볼 수 있지만 다중 리포지토리는 필요한 서비스에만 액세스할 수 있는 각 팀에 대해 별도의 리포지토리를 만듭니다. 프로젝트에 모노 리포지토리와 멀티 리포지토리를 조합하여 사용하려는 경우 다음을 수행할 수 있습니다. 메타여러 프로젝트 및 라이브러리를 관리하는 도구입니다.
Git을 배우기 위한 무료 리소스에도 관심이 있을 수 있습니다.