Architecture Decision Record모노레포 대 멀티레포
목차:
요약
이슈
우리 프로젝트는 세 가지 주요 범주의 소프트웨어를 개발합니다:
- 프런트엔드 GUI
- 미들웨어 서비스
- 백엔드 서버
개발할 때 우리의 소스 코드 관리(SCM) 버전 관리 시스템(VCS)은 git입니다.
git으로 코드를 어떻게 조직할지 선택해야 합니다.
최상위 선택은 “모노레포”, “폴리레포” 또는 “하이브리드”로 조직하는 것입니다:
- 모노레포는 모든 조각을 하나의 큰 저장소에 넣는다는 뜻입니다
- 폴리레포는 각 조각을 각자의 저장소에 넣는다는 뜻입니다
- 하이브리드는 모노레포와 폴리레포를 섞는다는 뜻입니다
자세한 내용은 https://github.com/joelparkerhenderson/monorepo-vs-polyrepo 를 참조하십시오
결정
조직/팀/프로젝트가 비교적 작고 빠른 반복이 안정성 유지보다 우선순위가 높을 때는 모노레포.
조직/팀/프로젝트가 비교적 크고 안정성 유지가 빠른 반복보다 우선순위가 높을 때는 폴리레포.
상태
결정됨. 모노레포 및/또는 폴리레포를 관리하기 위한 새 도구가 나오면 다시 검토할 수 있습니다.
세부 사항
가정
우리가 개발하는 모든 코드는 일반 대중이 아니라 한 조직의 제공물을 위한 것입니다. 즉 브로커-딜러는 일반 대중 자원봉사 개발자 같은 것을 갖추는 것을 목표로 하지 않습니다.
제약
제약은 https://github.com/joelparkerhenderson/monorepo-vs-polyrepo 에 잘 문서화되어 있습니다
입장
우리는 Google, Facebook 등의 방식인 모노레포를 검토했습니다. 모노레포의 확장 문제는 먼 미래의 일이므로, 그것이 필요해질 때쯤에는 Google이나 Facebook과 같은 관행을 활용할 수 있을 것이라고 생각합니다.
우리는 Google Android, Facebook React 등 전형적인 Git 오픈 소스 프로젝트 방식인 폴리레포를 검토했습니다. 이는 일반 대중의 참여(예: 전 세계 누구나 코드에 작업할 수 있음)와 개별적 가용성(예: 프로젝트가 다른 조각 없이 단독으로 사용됨)에 최선의 선택이라고 생각합니다.
논거
조직/팀/프로젝트가 비교적 작을 때는 빠른 반복이 안정성 유지보다 우선순위가 훨씬 높으므로 모노레포를 선택합니다
조직/팀/프로젝트가 비교적 클 때는 안정성 유지가 빠른 반복보다 우선순위가 훨씬 높으므로 폴리레포를 선택합니다.
영향
CI+CD용 파이프라인이 이미 있다면 하나의 저장소 안에서 여러 프로젝트를 테스트하도록 조정해야 할 수 있습니다.
CI+CD는 모노레포의 모든 프로젝트를 빌드할 수 있으므로 모노레포의 전체 빌드에 더 많은 시간이 걸릴 수 있습니다.
조직/팀/프로젝트가 성장하면 모노레포는 확장 문제를 겪게 됩니다.
모노레포의 확장 문제는 폴리레포로의 전환을 점점 더 가치 있게 만들 수 있습니다.
모노레포에서 폴리레포로의 전환은 상당한 데브옵스 작업이며 계획, 관리, 프로그래밍이 필요합니다.
관련 항목
관련 결정
모노레포(예: Google Bazel)와 폴리레포(예: Lyft Refactorator)를 관리하기 위한 관련 도구에 대한 결정을 작성할 것입니다.
관련 요구사항
CI+CD 파이프라인이 git과 잘 작동하도록 개발해야 합니다.
관련 산출물
저장소 조직에는 프로비저닝, 구성 관리, 테스트 및 유사한 데브옵스 영역을 위한 관련 산출물이 있을 것으로 예상합니다.
관련 원칙
쉽게 되돌릴 수 있음. 모노레포가 실제로 작동하지 않거나 리더십이 원하지 않으면 폴리레포로 바꾸기가 간단합니다.
고객 집착. 우리는 프로젝트를 고객의 손에 쥐여 주는 것을 중시하며, 모노레포가 폴리레포보다 더 빨리 그곳에 도달하게 하고 더 빠르게 반복하는 데도 도움이 된다고 믿습니다.
크게 생각하기. Google과 Facebook은 모든 핵심 제공물을 함께 개발/테스트/배포할 수 있으므로 폴리레포보다 모노레포를 매우 강하게 옹호합니다.
메모
여기에 메모를 추가하십시오.