분류 기타

Monorepo 개발의 핵심 - 단일 코드 저장소에서 전체 프로젝트를 빌드하는 방법

컨텐츠 정보

  • 조회 208 (작성일 )

본문

monorepo라는 단어는 그리스 단어 mónos (혼자만의 번역본)와 단어 저장소의 약어 인 "모노"의 조합입니다. 

축어적으로 취한 간단한 개념 : 외로운 저장소 하나. 도메인은 소프트웨어 엔지니어링이므로 소스 코드, 멀티미디어 자산, 바이너리 파일 등을 위한 홈을 가리 킵니다. 그러나 이 정의는 빙산의 일각에 불과합니다. 

실제로는 모노 리포가 훨씬 더 많기 때문입니다.


https://www.freecodecamp.org/news/monorepo-essentials/ 


이 기사에서는 회사가 소유하고 있는 모든 코드를 동일한 저장소에 보관하는 장단점을 찾아 낼 계획입니다. 결국 당신은 왜 이런 식으로 일해야 하는지, 어떤 도전을 할 것인지, 어떤 문제를 해결할 것인지, 얼마만큼 투자해야 하는지에 대해 좋은 생각을 가지고 있어야 합니다.


1*pCRpcpi3mLE2I-e4FOnp5w.png 


위의 차트에서 볼 수 있듯이 용어 자체는 2017 년 새 것처럼 보입니다. 그러나 이전에는 아무도 자신의 코드를 모두 한 곳에 저장하지 않았다고 생각하는 것은 실수입니다. 

실제로 2009 년 첫 직장에서 나는 모든 프로젝트를 하나의 SVN 저장소 (프로젝트 당 하나의 디렉토리)에 저장했습니다. 실제로 이 연습을 더 잘 추적 할 수 있을 것입니다. 그러나 최근 폭발적인 인기를 어떻게 설명 할 수 있을까요?


실제로 코드를 단일 지점에 저장하는 것이 주요 판매 포인트가 아닙니다. 

지난 몇 년 동안 주요 기술 회사 인 Google, Facebook 또는 Dropbox는 동일한 저장소에서 거대한 규모로 함께 작업하는 방식을 과시했습니다. 

하나의 저장소 내에서 수천 명의 엔지니어가 공동 작업하는 조직은 놀라운 일입니다. 그리고 어려운 공학 문제. 사실 이러한 회사는 개발자가 생산적으로 작업 할 수 있는 도구와 시스템에 많은 돈을 투자합니다. 

이러한 시스템은 차례로 당신이 깨닫지 못할 수 도 있는 문제를 해결했습니다. 이것은 기술 회담을 하는 동안 사람들을 매료 시킵니다. 이것은 2017 년 이후로 검색을 주도 해왔습니다.


Google의 프론트 엔드 개발, Alex Eagle :

https://medium.com/@Jakeherringbone/you-too-can-love-the-monorepo-d95d1d6fcebe


Google monorepo 프리젠 테이션, Rachel Potvin : 

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


페이스 북의 코드베이스 크기에 맞게 Mercurial을 확장 한 Durham Goode :

https://code.fb.com/core-data/scaling-mercurial-at-facebook/


나는 Google이나 Facebook이 검토 한 monorepo가 ​​제공하는 몇 가지 핵심 기능을 확인했습니다. 

이것은 분명히 철저한 목록은 아니지만 좋은 출발점입니다. 이 점들 각각에 대해 토론 할 때, 나는 삶이 어떻게 생겼는지, 그리고 정확히 무엇이 해결되는지를 고려했습니다. 

물론 우리의 작업 분야에서는 모든 것이 절충되고 자유로운 것이 아닙니다. 내가 명단을 작성한 모든 프로에 대해 나에게 직접적으로 모순되는 유스케이스를 발견 할 것이지만, 그렇다고 해도 괜찮습니다.


언어에 상관없이 모든 코드는 하나의 저장소에 있습니다. 


한 번에 모든 것을 저장하는 첫 번째 이점은 즉시 명백하지 않을 수도 있지만 개발자로서 모든 것을 자유롭게 탐색 할 수 있다는 것은 큰 영향을 줍니다. 그것은 일종의 팀 정신을 조장하는 데 도움이 되며 또한 정보를 배포하는 데 매우 가치 있고 저렴한 방법입니다. 

귀사에서 개발 중인 프로젝트가 무엇인지 물어 본 적이 있습니까? 과거와 현재? 어떤 팀이 궁금한가요? 특정 엔지니어링 문제를 어떻게 해결 했습니까? 

그들은 단위 테스트를 어떻게 작성하고 있습니까?


monorepo에 직접적인 반대에서 우리는 multirepo 구조가 있습니다. 

각 프로젝트 또는 모듈은 별도의 공간을 확보합니다. 그러한 시스템에서 개발자는 위에 나열된 질문에 대한 답변을 얻기 위해 상당한 시간을 할애 할 수 있습니다. 작품의 분산 된 특성은 구독 할 수 있는 단일 정보 출처가 없음을 의미합니다.


내 목록에서 이 기능 만 따라 멀티 레프트 레이아웃에서 모노 레포 레이아웃으로 전환 한 회사가 있습니다. 그런 구조는이 기사의 화제와 혼동되면 안된다. 대신 배치 된 멀티 레포로 정의 할 수 있습니다. 

예, 모든 것이 한 곳에서 이루어 지지만 이 목록의 나머지 기능은 훨씬 더 흥미롭습니다.


모듈 간 종속성을 통제되고 명시적인 방식으로 구성 할 수 있습니다. 


기존의 전투 테스트에서 종속성을 처리하는 방법은 지속적인 통합 시스템과 별도의 저장소 시스템에 또는 심지어 개발 시스템에서 수동으로 버전을 게시하는 것입니다. 

나중에 검색하기 쉽도록 버전 관리 (또는 태그 지정)됩니다. 이제 멀티 레포 설정에서 각 프로젝트에는 동일한 회사 내부에서 게시 된 외부 원본 (제 3 자) 또는 내부의 종속성 집합이 있습니다.


한 팀이 다른 사람의 코드에 의존하려면 모든 것이 종속성 관리 스토리지 시스템을 통과해야 합니다. 예를 들면 npm, MavenCentral 또는 PyPi가 있습니다. 나는 이전에 모든 것을 한 곳에 모아서 간단히 배열 된 멀티 레포를 만들 수 있다고 말했다. 그러한 시스템은 간접적으로 관찰 가능하다. 

왜 그것이 중요한지 살펴 보겠습니다.


개발자로서 우리의 시간은 코드를 읽고 쓰는 것 사이에서 매우 불균등하게 나뉘어집니다. 이제 종속성의 근본 원인을 가진 문제를 디버깅해야 한다고 상상해보십시오. 그게 어려운 문제이기 때문에 제 3자를 여기에서 배제 할 수 있습니다. 아니요.이 문제는 회사의 다른 팀에서 게시 한 패키지에서 발생합니다. 프로젝트가 최신 버전에 달려 있다면 운이 좋습니다!