REPO 스타일 WAR : MONO vs MULTI

** 주의 : 번역이 제대로 되지않아 불편할 수도 있습니다. 단, 1명에게라도 도움이 되려 작성된 글입니다.**

Repo Topology 의 기본법칙은 repo 사이에 주기적인 의존성을 가져서는 안된다는 것이다.

만약 라이브러리를 업데이트하려면 일련의 비원자적(non-atomic) 변경을 수행하여 절망의 세계에 빠져 때가 있는 경우가 있다.

mono repo를 사용하면 repo가 하나이므로 이러한 문제가 발생하지 않는다는 장점이 있다. 반면에 mono repo는 개발 프로세스나 개발 철학 관한 것 의미를 포함다.

Two philosophies(두가지 철학)

mono repo 와 multi repo 철학의 근복적인 차이는 가장빠른(to go fastest) 시스템에서 작업을 함께 일하는 팀에게 허용하는 것에 대한 차이다.

극단적인 형태로 multi repo 볼때, 만약 모든 하위 팀들이 그들이 원하는 라이브러리, 작업도구, 개발플로우 등을 사용해서 작업할 수 있도록 융통성을 가진다. 생산성은 극대화 할 것이다.

명백하게 비용은 해당 repo 내에 개발되지 않은 어떤 것도 그것이 third-party library나 서비스인 것처럼 소비되어야 한다는 것입니다, 그것이 책상 위에 앉아 있는 사람에 의해서도 말이죠.

예를 들어, 사용하는 라이브러리에서 버그가 발견되면 알맞은 repo에 버그를 수정하고, 새로운 artifact를 배포하고, repo로 돌아가 코드를 변경해야 한다.

다른 repo 에서는 다른 code base 뿐만 아니라 잠재적인 libaries, tools, 심지어 다른 workflow 도 처라해야 한다. 아니면 그 시스템을 소유하고 있는 사람이 변경을 일으켜때 까지 기다려야 할 수도 있다.

반면 mono repo 관점에서 특히 복잡한 의존성 그래프를 다루는 경우 마찰(friction)이 multi repo 옹호자가 인식하는 것보다 훨씬 더 비싸며 다른 팀이 자신의 방식대로 움직이게 됨으로써 얻게 되는 생산성 향상은 그렇지 않다

일부팀에서는 지역적 최적의 작업 방법을 찾을수 있지만, 그들의 이득은 아마도 다른 팀들이 화물 곡선을 그리며 작업하도록 하는, 차선책을 선택하는 다른 팀들에 의해 상쇄될 수 있다.

Monorepos는 한 바구니에 당신의 모든 달걀을 넣는 것으로 당신은 그 바구니를 주의 깊게 보는데 투자할 여유가 있다.

다른 repos 에서는 변경해야 한다는 점, 또는 다른 팀이 변경할 때까지 기다려야 한다는 점 등의 마찰은 누구나 변화할 수 있고 실제로는 어떠한 것도 변경하지 않기 때문에 대체로 mono repo 에서는 피할 수 있다.

만약 여러분이 라이브러리에서 bug 를 발견한다면, 여러분은 그것을 고칠 수 있고 더 이상의 마찰 없이 여러분의 삶을 살아갈 수 있습니다.

그러나 이것은 아마도 mono repo와 multi repo 철학 사이의 가장 현저한 실용적인 차이점, 즉 라이브러리 변화를 처리하는 데 필요한 변경을 누가 담당 할 것인가에 달려 있습니다.

즉, 라이브러리 X의 소유자가 API를 변경하면 누가 X를 사용하는 코드를 수정합니까? mono repo는 전체 구조가 깨끗할 때까지 자신의 변경 사항을 확인할 수 없기 때문에 라이브러리 X의 작성자가 되어야 합니다. 그들은 변경이 발생할 코드를 찾아 수정해야 합니다. 다시 말해, 라이브러리 저자들은 스스로가 고치려고 하기 때문에, 그들이 깨어 있는 모든 코드를 고치는 비용과 변화의 이익 사이에서 균형을 이루어야 한다.

반면 multirepo 세계에서는 라이브러리 X 사람들이 단순히 자신의 repo에 대한 변경 사항을 확인한 다음 새로운 버전이있는 유물을 게시하고 다른 레포지에서 일하는 팀에게 어느 시점에 이르기까지 의존합니다. X를 최신 버전으로 변경하고 필요한 모든 사항을 변경해야합니다

다시, 이 선택은 여러분이 무엇이 개발자들을 가장 빨리 진할 할 것이라고 생각하는가에 달려 있다. 라이브러리 작성자의 경우 다중 접근 방식을 사용하면 단기적으로는 작업이 더 적게 필요합니다. 즉, 원하는 변경 작업을 수행하고 새 바이너리를 게시하기만 하면 됩니다. 그리고 도서관의 소비자들은 도서관 X의 변화를 처리해야 하기 때문에 지체되지 않는다. 그리고 그들의 코드 베이스는 누군가가 들어와 그것을 사용하도록 하여 피해를 입지 않는다

하지만 세상에 공짜는 없다. 장기적으로, 라이브러리 유지 관리자와 라이브러리 사용자는 단기적 이득에 대해 돈을 지불한다. 유지 관리자는 모든 사용자가 즉시 업그레이드하지 않기 때문에 여러 버전의 라이브러리를 지원해야 합니다. 그리고 소비자들은 결국 새로운 버전의 상품으로 업그레이드할 필요가 있을 뿐만 아니라, 그들이 의존하는 다른 코드가 아직 업그레이드 되지 않았기 때문에 그들이 원할 때는 업그레이드를 막을 수 없다.

Implications(의미) of a monorepo

mono repo를 운영하는 주된 도전과제는 시간이 지남에 따라 자연스럽게 확장되고 수평적 확장이 불가능할 경우(multi repo 로 분할에 의해서 ) 수직 확장이 필요하다 그러나 모든 툴이 과제에 부학되는 것은 아닙니다.

특히

source 와 intelligently caching built artifacts 의 모두 빌드하기 위해 특수한 빌드 도구가 필요하다. 구글의 바젤(Bazel), 페이스북의 벅 (Facebook 's Buck), 트위터의 팬츠가 아마도 베이젤에게 가장 유력한 후보입니다.
만약 repo 가 너무 커지면, 표준 버젼 관리는 그것에 질식할 수도 있다 . Git 는 리눅스 커널을 처리할 수 있지만 그다지 큰 문제는 아닙니다. Github는 수평적 확장에 중점을 두었지만, 작은 repo 만 쏟아 부을 뿐, 진정으로 큰 single repo 를 작성할 준비가 되어 있는지는 명확하지 않습니다. 트위터는 아마도 전 세계에서 가장 큰 일체적인 monolithic git repo 를 운영하고 있고 그것을 처리하는 것은 여전히 매우 힘들다. 반면에, 페이스북의 중상 모략적인 해킹은 가능하며, 여러분이 아무 문제 없이 그것에 쏟아 붓는 어떤 것도 아마도 처리할 수 있을 것이다. 다시 말해, 사람들은 여전히 git를 사용하여 만약 그것이 딸꾹질을 하지 않고 현재의 코드 베이스와 개발자 수를 처리할 수 있다면, 여러분은 당분간 git repo 를 재배할 충분한 여유가 있을지도 모릅니다.
그것은 Git과 Mercurial 모델을 상대로 repo의 서브셋을 체크합니다. 어떤 경우라도 mono repo에서 임의의 타겟을 구축하기 위해 체크 아웃해야 할 사항을 파악하기 위해 툴링 지원이 필요합니다.
IDE는 큰 작업 공간 또는 비표준 제작 도구와 관련하여 문제가 있을 수 있다. (비록 Bazel이 Intell. 통합과 팬츠에 대한 지지를 받지 못한 것 같았지만. 페이스북은 그들 자신의 IDE를 만들어 이 문제를 해결했다.)

Some other considerations:

모든 코드가 한 곳에 있으므로 모든 코드를 묶어 놓는 데 자연스러운 장벽이 거의 없습니다. 그러므로 좋은 전반적인 구조를 유지하려면 끊임없이 경계해야합니다. 더하기 측면에서 전역 리팩터링이 가능합니다.
공개 오픈 소스 프로젝트를 개발할 경우 해당 프로젝트에 대한 monorepo의 이점을 얻지 못하거나 Github에 코드를 동기화하는 데 신경을 쓰지 않아도됩니다. 사용자가 극도로 공상적 인 경우가 아니면 외부 작성자의 경험은 2 등입니다. (그들은 Github PR을 병합시키면서 보낼 수 없으며, 그 대신 monorepo 내부에 적용되어 궁극적으로 Github에 다시 게시됩니다.)
버전 관리 : mono repos 에서는 마스터의 모든 것이 같은 버전입니다. 마스터에있는 것과 배포 된 것 사이에 여전히 간격이있을 수 있습니다. 특히 일부 프로젝트가 실제로 지점을 구축하여 건전성을 위해 구축하는 경우.

Implications(의미) of a multirepo

아마도 multi repo 의 가장 큰 장점은 기존 도구가 이미 single repo 에 넣을 가능성이있는 프로젝트의 규모를 처리하도록 설계 되었기 때문에 mono repo 의 툴링 문제를 피할 수 있다는 것입니다. 그러나 multi repo 접근법을 통해 얻을 수 있다고 믿더라도 다른 문제가 있습니다.

productivity gains:

버전을 관리하고 그것이 의존하는 라이브러리의 새 버전을 사용하도록 코드를 업데이트하는 비용을 절감하는 것에 대해 매우 엄격하고 고의적이어야합니다. 업데이트 의존성을 전 세계적으로 추적하여 사람들에게 언제 업데이트해야하는지에 대한 적절한 이해를 제공해야 할 수도 있습니다.
multi repos 가 프로젝트간에 일정한 느슨한 커플링을 강요하는 방법은 결합해야 할 것들을 분리해야하거나 분리 된 것들을 더 가깝게 결합해야한다고 현실이 지시 할 때 단점이됩니다. 이 도구를 사용하면 끔찍한 짓을하지 않아도됩니다.
multi repo 에서 작업해야하기 때문에 야기되는 문제를 완화하려면 도구, 컨벤션 등의 표준화를 제공하는 것이 좋습니다. 이것은 멀티 레포 철학의 기본 교리를 상쇄하지만.
처음에는 올바른 repo를 찾아야 할 때 코드 찾기가 더 어려워집니다.

최소한 빌드 파일의 의존성을보고 다른 사람이 찾을 필요가있는 repo 를 파악할 수있게 해주는 일종의 repos 또는 강력한 명명 규칙을 유지해야 할 것입니다.

Best of both worlds?

어떻게 든 두 세계의 장점을 얻을 수 있습니까? 아마도 그렇지 않습니다.

multi repos를 하나의 mono repo처럼 행동하게하려면 multi repo 주위로 도구를 만들 수 있습니다 (이것은 Android가 repo라는 도구로 수행하는 것입니다). 그러면 일관된 툴체인을 설정할 수 있습니다.

모든 repos에서 다른 repos 의 변경 비용을 줄입니다.

그러나이 시점에서 별도의 repo 에 코드가있는 다른 이유가 없으면 multi repo 에서 어떤 이점이 있는지 명확하지 않습니다.

또는 monorepo에서, 당신은 multirepo에서 얻을 수있는 지역 안정성을 모방하기 위해 가지를 사용할 수 있습니다. 모든 프로젝트는 오래 지속되는 지점에 살고 필요할 때 다른 프로젝트의 변경 사항 만 병합합니다.

그러나 당신은 당신이 실제로 원할 때 업그레이 드를 방해하는 돌이킬 수없는 다이아몬드 의존성에 대한 모든 잠재력을 얻습니다.

참조

REPO STYLE WARS: MONO VS MULTI