모노레포

Monorepo

버전 관리 시스템에서 모노레포('싱글'을 뜻하는 모노'와 '리포지토리'의 줄임말인 '리포')는 많은 프로젝트의 코드가 동일한 저장소에 저장되는 소프트웨어 개발 전략입니다.이러한 소프트웨어 엔지니어링 관행은 적어도 '공유 코드 기반'[1]으로 알려진 2000년대 [1]초반으로 거슬러 올라갑니다.관련 개념은 모노리스이지만 모노리스는 서브프로젝트를 하나의 큰 프로젝트로 결합하는 반면 모노레포는 독립된 프로젝트를 [2][3][4]포함할 수 있습니다.

Google,[5] Facebook,[6] Microsoft,[7] Uber,[8] Airbnb 및[9] Twitter는 모두 매우 큰 모노레오를 채용하고 있으며, 다양한 전략으로 빌드 시스템과 버전 관리 소프트웨어를 확장하여 대량의 코드와 매일의 변경에 대응하고 있습니다.

이점

개별 [5][10]리포지토리에 비해 모노레포에는 다음과 같은 여러 가지 잠재적인 이점이 있습니다.

  • 코드 재사용의 용이성– 유사한 기능 또는 통신 프로토콜을 공유 라이브러리에 추상화하여 프로젝트에 직접 포함할 수 있습니다.의존 패키지 매니저는 필요 없습니다.
  • 심플한 의존관계 관리– 여러 프로젝트가 서드파티 의존관계에 의존하는 복수 저장소 환경에서는 그 의존관계가 여러 번 다운로드 또는 구축될 수 있습니다.모노레포에서는 참조된 종속성이 모두 동일한 코드베이스에 존재하므로 빌드를 쉽게 최적화할 수 있습니다.
  • ATOMIC 커밋 – 함께 작동하는 프로젝트가 개별 저장소에 포함되어 있는 경우 릴리스는 어떤 버전의 프로젝트가 다른 버전과 동작하는지 동기화해야 합니다.또한 대규모 프로젝트에서는 의존관계 간에 호환되는 버전을 관리하는 것이 의존관계의 [8]지옥이 될 수 있습니다.모노레포에서는 [11]개발자가 여러 프로젝트를 원자적으로 변경할 수 있기 때문에 이 문제를 무시할 수 있습니다.
  • 대규모 코드 리팩터링– 개발자는 프로젝트 전체에 액세스 할 수 있기 때문에 리팩터는 리팩터 후에도 프로젝트의 모든 부분이 계속 기능하도록 할 수 있습니다.
  • 팀 간 콜라보레이션– 소스 의존성(소스에서 [9]컴파일된 의존성)을 사용하는 모노레포에서는 팀은 다른 팀이 작업 중인 프로젝트를 개선할 수 있습니다.이를 통해 유연한 코드 소유가 가능합니다.

제한 및 단점

  • 버전 정보 손실 – 반드시 필요한 것은 아니지만 일부 모노레포 빌드에서는 저장소 내의 모든 프로젝트에서 하나의 버전 번호를 사용합니다.이로 인해 프로젝트별 의미 버전 관리가 [12]손실됩니다.
  • 프로젝트별 액세스 제어 부족– 분할 저장소를 사용하면 필요에 따라 저장소에 대한 액세스를 허용할 수 있습니다.모노레포를 사용하면 프로젝트의 모든 소프트웨어에 대한 읽기 액세스가 허용되므로 새로운 보안 [13]문제가 발생할 수 있습니다.이 제한이 문제가 되지 않는 버전 관리 시스템이 있습니다.예를 들어 Subversion을 사용하면 레포의 모든 부분(단일 디렉토리라도)을 다운로드할 수 있으며 경로 기반 인증을 사용하여 저장소의 특정 부분에 대한 액세스를 제한할 수 있습니다.
  • 기본적으로 더 많은 스토리지가 필요합니다.저장소가 분할되어 있으면 기본적으로 관심 있는 프로젝트만 가져옵니다.모노레포를 사용하면 기본적으로 모든 프로젝트를 체크아웃합니다.이 경우 상당한 스토리지 공간을 차지할 수 있습니다.모든 버전 관리 시스템에는 부분적인 체크 [14][15][16]아웃을 실행하는 메커니즘이 있지만, 그렇게 하면 모노레포의 장점 중 일부가 사라집니다.

스케일러빌리티의 과제

대규모 프로젝트를 수행하는 기업은 특히 빌드 도구와 버전 관리 [6]시스템과 관련하여 모노레포스의 장애물에 부딪혔습니다.세계에서 가장 큰 것으로 추측되는 구글의 모노레오는 초대형 시스템의[5] 분류를 충족하며 [17]80테라바이트 이상의 저장소에서 매일 수만 건의 기부를 처리해야 한다.

확장 버전 관리 소프트웨어

다음 항목도 참조하십시오.버전 관리

기존 버전 관리 소프트웨어를 사용하거나 기존 버전 관리 소프트웨어로 전환하는 기업은 소프트웨어가 대규모 모노레포에 필요한 데이터 양을 효율적으로 처리할 수 없다는 것을 알게 되었습니다.페이스북과 MS는 각각 기존 버전 관리 소프트웨어인 머큐리얼과 Git에 기여하거나 포크를 선택했고 구글은 결국 자체 버전 관리 시스템을 만들었다.

10년 이상 동안 구글은 Perforce가 단일 머신에서 호스팅하는 것에 의존해 왔다.2005년에 구글의 빌드 서버는 한 번에 최대 10분 동안 잠길 수 있었습니다.Google은 2010년에 [18]이를 30초-1분으로 개선했습니다.확장 문제로 구글은 결국 [5]Piper라는 자체 분산 버전 관리 시스템을 개발했다.

Facebook은 버전 관리 시스템인 Mercurial에서 성능 문제가 발생하여 [19]클라이언트에 업스트림으로 기여하였고, 2014년 1월에는 [20]Git의 경쟁 솔루션보다 더 빠르게 만들었습니다.

2017년 5월 마이크로소프트는 거의 모든 윈도 엔지니어들이 Git 모노레포를 [7]사용한다고 발표했다.이 과정에서 마이크로소프트는 [21]Git용 Virtual File System으로 불필요한 파일 액세스를 제거하고 대용량 파일 처리를 개선하기 위해 Git 클라이언트에 상당한 업스트림 기여를 했습니다.

빌드 소프트웨어의 확장

다음 항목도 참조하십시오.자동화 구축

모노레포에서 [9]제대로 작동하는 빌드 툴은 거의 없으며 체크인 시 전체 저장소의 빌드 및 지속적인 통합 테스트가 수행되는 흐름으로 인해 성능 [12][13]문제가 발생합니다.방향 그래프는 Buck, Bazel, Pants와 같은 시스템을 구축하며, 빌드 및 테스트를 [22]개발의 활성 영역으로 구분하여 해결하십시오.

트위터는 2011년부터 팬츠 개발을 시작했는데,[23] 당시 페이스북의 벅과 구글의 바젤은 비공개 소스였다.2012년 Apache 2.0 [24]라이선스로 트위터 오픈 소스 팬츠.

Go 기반의 빌드 시스템인 Please는 2016년 구글의 Bazel에서 영감을 받아 페이스북의 [25]Buck에 불만을 품은 Think Machine에 의해 개발되었다.

레퍼런스

  1. ^ a b Mark "Nurgle." Collins (2001). Linux Game Programming. Prima Tech. ISBN 978-0-7615-3255-2. OCLC 1044194694.
  2. ^ "From Monolith to Monorepo". 7 November 2017.
  3. ^ "Misconceptions about Monorepos: Monorepo != Monolith". 19 November 2019.
  4. ^ "Monorepos in the Wild". 4 April 2019.
  5. ^ a b c d Levenberg, Rachel Potvin, Josh (July 2016). "Why Google Stores Billions of Lines of Code in a Single Repository". Communications of the ACM. Retrieved 20 July 2018.
  6. ^ a b GOODE, DURHAM; Rain (7 January 2014). "Scaling Mercurial at Facebook – Facebook Code". fb code. Retrieved 24 July 2018.
  7. ^ a b Lardinois, Frederic (24 March 2017). "Microsoft now uses Git and GVFS to develop Windows". TechCrunch. Retrieved 20 July 2018.
  8. ^ a b Aimee Lucido (7 April 2017). Uber Technology Day: Monorepo to Multirepo and Back Again. Retrieved 24 July 2018.
  9. ^ a b c Dorothy Ordogh (5 April 2018). Pants and Monorepos. Retrieved 24 July 2018.
  10. ^ Brousse, Nicolas (2019). "The issue of monorepo and polyrepo in large enterprises". Proceedings of the Conference Companion of the 3rd International Conference on Art, Science, and Engineering of Programming. ACM Digital Library. pp. 1–4. doi:10.1145/3328433.3328435. ISBN 9781450362573. S2CID 201670751. Retrieved 7 September 2019.
  11. ^ Santacroce, Ferdinando; Olsson, Aske; Voss, Rasmus; Narebski, Jakub (2016). Git: Mastering Version Control. Packt Publishing Ltd. p. 756. ISBN 9781787122796.
  12. ^ a b Farina, Matt. "Dangers of Monorepo Projects - DZone DevOps". DZone. Retrieved 20 July 2018.
  13. ^ a b 点融黑帮 (16 August 2017). "浅谈monorepo" [Talking about monorepo]. Sohu (in Chinese). Retrieved 20 July 2018.
  14. ^ git 부분 클론
  15. ^ Svn Book: 스퍼스 디렉토리
  16. ^ Perforce: 클론
  17. ^ Metz, Cade (16 September 2015). "Google Is 2 Billion Lines of Code—And It's All in One Place". WIRED. Retrieved 20 July 2018.
  18. ^ Bloch, Dan. "Still All on One Server: Perforce at Scale" (PDF). Retrieved 23 July 2018.
  19. ^ Claburn, Thomas. "Facebook is writing a Mercurial server in Rust. This is not a drill". The Register. Retrieved 20 July 2018.
  20. ^ Blewitt, Alex (9 Jan 2014). "Facebook makes Mercurial faster than Git". InfoQ. Retrieved 24 July 2018.
  21. ^ Bright, Peter (24 May 2017). "Windows switch to Git almost complete: 8,500 commits and 1,760 builds each day". Ars Technica. Retrieved 20 July 2018.
  22. ^ Hammant, Paul; Smith, Steve. "Trunk Based Development". trunkbaseddevelopment. Retrieved 24 July 2018.
  23. ^ Mohilo, Dominik (10 June 2016). "8 Build-Tools im Vergleich: Ant – Buildr – Maven – Bazel – Buck – Gradle – Pants – sbt - JAXenter" [8 build tools compared: Ant - Buildr - Maven - Bazel - Buck - Gradle - Pants - sbt]. JAXenter (in German). Retrieved 20 July 2018.
  24. ^ Moore, Madison (3 May 2016). "GitLab releases security fixes, Pants 1.0, and Sauce Labs integration for JIRA—SD Times news digest: May 3, 2016 - SD Times". SD Times. Retrieved 20 July 2018.
  25. ^ Ebden, Peter (December 2017). "Please - the Thought Machine Build System". Blog. Thought Machine. Archived from the original on 2019-12-28.