Ledger Live Monorepo 프로젝트: 1부 – 문제(고통을 야기함) | 원장

이 블로그 게시물 시리즈에서 Ledger Live 개발자인 Valentin De Almeida는 지난 수년간 Ledger Live 코드베이스의 발전에 대해 이야기합니다. 이 블로그 게시물에서는 처음에는 다중 저장소 기반이었다는 사실과 그 과정에서 직면한 문제, 그리고 단일 저장소 아키텍처로 발전해야 했던 이유에 대해 알아봅니다. 다음 블로그 게시물에서는 이 대규모 마이그레이션 프로젝트가 어떻게 수행되었는지 설명하겠습니다. 

약간의 역사 

2020년과 2021년 Ledger의 성장은 상당했습니다. 우리는 공격적으로 새로운 인재를 채용하여 소수의 개발자에서 20명이 넘는 개발자로 팀을 확장했습니다. 이는 기존 프로젝트에 많은 새로운 엔지니어가 합류했음을 의미합니다. 우리 팀이 빠르게 성장함에 따라 신속하게 해결해야 하는 새로운 과제에 직면했습니다. 이러한 새로운 어려움에도 불구하고 우리는 목표에 집중하고 계속해서 뛰어난 작업을 수행했습니다.

우리는 한발 물러서서 점점 더 많은 사람들이 프로젝트에 참여할 때 발생하는 새로운 문제를 조사했습니다. 이러한 새로운 과제 중 다음과 같은 요구 사항을 나열할 수 있습니다.

• 더 간단한 흐름.
• 유입 및 외부 기여자를 위한 더 나은 지침.
• 통합된 도구 세트입니다.
• 더 나은 종속성 관리.
• 중앙 집중식 오픈 소스 기여.

최신 기술: 마이그레이션 전

처음부터 작년까지 Ledger Live는 모바일 및 데스크톱 프런트 엔드와 그 뒤에 있는 모든 논리를 위한 다중 저장소 아키텍처를 기반으로 했습니다. 이런 방식으로 작업하기로 한 것은 의식적인 결정이 아니었지만 실제 아키텍처 리드가 없는 확장 프로젝트의 결과일 뿐이었습니다. Ledger Live는 Nano 사용자들에게 가장 안전하고 최고의 앱을 제공하기 위해 다양한 구성 요소를 하나로 모으는 프로젝트이며, 이를 코드베이스에 반영했습니다.

우리가 가지고 있는 흐름은 기껏해야 불안정했습니다. 주로 몇 년 전만 해도 우리가 6~7명의 개발자였기 때문입니다. 관련된 당사자가 적었기 때문에 의사소통이 훨씬 더 쉬워졌고 우리는 그 일을 무사히 처리했습니다. 그럼에도 불구하고 우리가 작업하는 방식, 특히 개발자 경험과 출시 프로세스와 관련하여 몇 가지 문제점이 있었습니다.

개발 경험 병목 현상

종속성

프로젝트의 특성상 우리는 여러 저장소를 동시에 종속성으로 작업합니다. 다음은 간단한 개요입니다.

Ledger 오픈 소스 라이브러리는 비즈니스 로직에서 사용되며, 이후 데스크톱 및 모바일 앱 모두에서 사용됩니다. 그러나 이러한 앱은 오픈 소스 라이브러리도 사용하고 동일한 라이브러리의 두 가지 다른 버전(예: @ledgerhq/errors 예를 들어) 앱이 중단될 수 있습니다.

한쪽 버전을 올려놓고 라이브러리를 게시한 다음(예, npm에!!!), 작동하지 않으면 다시 시도해야 했습니다. 우리는 의지하기 시작했습니다 yalc 여러 계층의 종속성(예: 오픈 소스 라이브러리에서 비즈니스 로직으로, 비즈니스 로직에서 앱으로)이 없는 한 프로젝트를 심볼릭 링크하는 것은 대부분 괜찮았습니다. 우리는 잠정적으로 협력하려고 노력했습니다. yarn link 뿐만 아니라 React Native에서는 운명이 정해진 것 같습니다.

지원

다양한 프로젝트의 최신 코드를 모두 사용하여 통합 테스트를 수행하는 것은 거의 불가능했습니다. 라이브러리를 레지스트리에 게시해야 했기 때문에 최신 코드로 모든 구성 요소를 테스트하는 것은 악몽이었습니다.

또한 로직이 중복된 여러 CI를 유지해야 했습니다.

컨텍스트 전환

항상 여러 코드 편집기/프로젝트/디렉토리를 이동하면 개발 경험이 정말 약해 보였습니다.

릴리스 프로세스 병목 현상

버전 관리

특히 여러 계층의 종속성이 있는 경우 다양한 프로젝트의 버전 관리를 처리하는 것이 어렵습니다.

출시

프로젝트가 분할되어 릴리스 추적이 복잡했고, 서로 다른 프로젝트의 릴리스를 관리해야 했습니다.

프로젝트가 서로 다른 저장소로 분할되어 있기 때문에 릴리스 프로세스를 자동화하는 것은 불가능했습니다.

물론 현재 시점에서는 Continuous Delivery를 생각할 수도 없었습니다.

가능한 해결책 ?

영감을 얻기 위해 주위를 둘러보면 모노 저장소 아키텍처가 우리가 놓친 핵심 부분인 것 같습니다. 그러면 훨씬 더 나은 개발 프로세스가 가능해집니다. 이 아키텍처를 중심으로 누락된 부분(릴리스, 자동화, 버전 관리 등)을 달성하는 데 도움이 되는 도구가 구축되어 있습니다.

그런데 모노 저장소란 무엇입니까?

기본적으로 모노 저장소는 다른 모든 관련 프로젝트(애플리케이션, 라이브러리, 도구)를 하나의 폴더/git 프로젝트 아래에 캡슐화하는 프로젝트입니다. 이를 통해 더 나은 종속성 관리, 도구 균일화(코드 스타일 및 TypeScript 구성 등), 중앙 집중식 지속적 통합, 통합 테스트, 사용된 패키지의 균일한 버전(예: 반응) 등이 가능합니다.

꽤 불가지론적인 시스템이기 때문에 우리가 발견하고 구현해야 할 일부 기능이 남아 있습니다. 빌드(순차 빌드, CI에 도움이 됨), 버전 관리, 변경 로그 생성에 조정을 추가하는 데 도움이 될 수 있는 몇 가지 훌륭한 커뮤니티 도구가 있기를 바랍니다. 이를 통해 릴리스 프로세스에서 누락된 작업을 완료할 수 있습니다.

단점

모노 리포지토리는 여러 개발자 또는 개발자 팀이 서로 종속성을 갖고 동시에 여러 프로젝트에서 작업하는 상황에서 의미가 있습니다. 그러나 설정 단계에서 약간의 복잡성이 추가됩니다(특히 4년의 역사와 활발한 개발이 이미 진행 중인 프로젝트의 경우). 언급할 가치가 있는 점은 프로젝트가 디스크 공간 측면에서 훨씬 더 커진다는 것입니다. 이제 모든 프로젝트는 동일한 폴더와 모든 종속성 아래에 있습니다. 어떤 테스트가 필수인가요? 언제 트리거해야 합니까?

장점

시간, 비용, 야망의 타당성을 평가한 후 이번 전환으로 예상되는 이점은 다음과 같습니다.

• 향상된 종속성 관리: 단일 저장소를 사용하면 서로 다른 프로젝트 간의 종속성이 모두 동일한 저장소에 저장되므로 관리하기가 더 쉽습니다. 이렇게 하면 원사 링크나 같은 해결 방법의 필요성이 줄어들 수 있습니다. yalc, 모든 프로젝트가 올바른 버전의 종속성을 사용하고 있는지 더 쉽게 확인할 수 있습니다.
• 더 나은 코드 구성: 모든 프로젝트와 해당 종속성이 단일 저장소에 저장되므로 모노레포를 사용하면 코드를 더 쉽게 구성할 수 있습니다. 서로 다른 프로젝트가 어떻게 조화를 이루고 서로 어떻게 의존하는지 이해하는 것이 더 쉽습니다.
• 향상된 개발자 경험: 단일 저장소를 사용하면 개발자가 여러 코드베이스나 저장소 간에 전환할 필요가 없기 때문에 여러 프로젝트에서 더 쉽게 작업할 수 있습니다. 또한 모든 코드가 동일한 저장소에 저장되므로 통합 테스트를 더 쉽게 실행할 수 있습니다.
• 향상된 자동화 및 지속적인 전달: 단일 저장소를 사용하면 코드 구축, 테스트, 릴리스와 같은 작업을 더 쉽게 자동화할 수 있습니다. 이는 릴리스 프로세스를 간소화하고 지속적 전달을 더 쉽게 구현하는 데 도움이 될 수 있습니다.
• 개발 속도가 향상되었습니다. 서로 다른 팀이 동일한 저장소에서 작업하므로 결과를 확인하기 위해 릴리스까지 기다릴 필요가 없으므로 통합이 가속화됩니다.

결론

전반적으로 모노레포 구조의 구현은 개발 프로세스를 개선하고, 릴리스 프로세스를 간소화하며, 개발자 경험을 향상시키는 데 도움이 될 수 있습니다.

이 시리즈의 다음 블로그 게시물에서는 이 주요 마이그레이션 프로젝트가 어떻게 수행되었는지, 사용한 도구, 선택 사항, 결과 등에 대해 안내해 드리겠습니다. 2부: 도구를 계속 지켜봐 주세요!

발렌틴 드 알메이다
개발자 경험 및 핵심 기술 – Ledger Live

• SEO 기반 콘텐츠 및 PR 배포. 오늘 증폭하십시오.
• PlatoData.Network 수직 생성 Ai. 자신에게 권한을 부여하십시오. 여기에서 액세스하십시오.
• PlatoAiStream. 웹3 인텔리전스. 지식 증폭. 여기에서 액세스하십시오.
• 플라톤ESG. 탄소, 클린테크, 에너지, 환경, 태양광, 폐기물 관리. 여기에서 액세스하십시오.
• PlatoHealth. 생명 공학 및 임상 시험 인텔리전스. 여기에서 액세스하십시오.
• 출처: https://www.ledger.com/blog/ledger-live-monorepo-project-part-1-problematics-make-it-pain