Ledger Live Monorepo プロジェクト: パート 1 – 問題点 (苦労する) | 元帳

このブログ投稿シリーズでは、Ledger Live 開発者の Valentin De Almeida が、長年にわたる Ledger Live コードベースの進化について語ります。 このブログ投稿では、最初はマルチリポジトリベースであったこと、その過程で遭遇した問題、そしてなぜモノリポジトリアーキテクチャに進化する必要があったのかを学びます。 次回のブログ投稿では、この大規模な移行プロジェクトがどのように実施されたかについて説明します。 

歴史の少し 

2020年と2021年のレジャーの成長は顕著でした。 私たちは積極的に新しい人材を採用し、チームを数名から 20 名を超える開発者に拡大しました。 これは、多くの新しいエンジニアが既存のプロジェクトに参加したことを意味します。 私たちのチームが急速に成長するにつれて、すぐに対処しなければならない新たな課題に直面しました。 こうした新たな困難にも関わらず、私たちは目標に集中し続け、優れた成果を出し続けました。

私たちは一歩下がって、プロジェクトに参加する人が増えるにつれて生じる新たな問題を調査しました。 こうした新たな課題の中には、次のようなニーズが挙げられます。

• よりシンプルなフロー。
• 新規および外部の寄稿者向けのより良いガイドライン。
• 統一されたツールのセット。
• 依存関係管理の改善。
• 一元化されたオープンソースの貢献。

最先端技術: 移行前

当初、そして昨年まで、Ledger Live は、モバイルとデスクトップの両方のフロントエンドとその背後にあるすべてのロジックについて、ポリリポジトリ アーキテクチャに基づいていました。 このような方法で作業するという意識的な決定はありませんでしたが、実際のアーキテクチャ上の主導権がないまま拡大したプロジェクトの結果にすぎませんでした。 Ledger Live は、Nano ユーザーに最高かつ最も安全なアプリを提供するために、さまざまなコンポーネントを XNUMX つにまとめたプロジェクトであり、それがコードベースに反映されました。

私たちが導入していたフローは、せいぜい不安定なものでした。主な原因は、私たちが数年前に 6 人か 7 人の開発者だったという事実です。 関与する関係者が少なくなったので、コミュニケーションがはるかに簡単になり、問題を解決できました。 それでも、特に開発者エクスペリエンスとリリースプロセスに関して、私たちの作業方法にはいくつかの問題点がありました。

開発エクスペリエンスのボトルネック

依存関係

私たちのプロジェクトの性質上、私たちは複数のリポジトリ間に依存関係を持ちながら同時に作業します。 簡単な概要は次のとおりです。

Ledger オープン ソース ライブラリはビジネス ロジックによって使用され、その後、デスクトップ アプリとモバイル アプリの両方で使用されます。 ただし、これらのアプリはオープンソース ライブラリも使用しており、同じライブラリの XNUMX つの異なるバージョンを使用しています (例: @ledgerhq/errors たとえば) アプリが壊れる可能性があります。

一方のバージョンを上げてからライブラリを公開し (はい、npm!!!)、それが機能しなかった場合は再試行する必要がありました。 私たちは依存し始めました yalc プロジェクトにシンボリックリンクを設定します。これは、複数の依存関係レイヤー (たとえば、オープン ソース ライブラリからビジネス ロジック、次にビジネス ロジックからアプリ) がない限り、ほとんど問題ありませんでした。 暫定的に協力してみました yarn link も同様ですが、React Native では運命にあったようです。

テスト

さまざまなプロジェクトの最新コードをすべて使用して統合テストを行うことはほぼ不可能でした。 ライブラリをレジストリに公開する必要があるため、最新のコードを使用してすべてのコンポーネントをテストするのは悪夢のような作業でした。

また、ロジックが重複した複数の CI を保守する必要もありました。

コンテキストの切り替え

常に複数のコード エディター、プロジェクト、ディレクトリを移動するため、開発エクスペリエンスが非常に貧弱に見えました。

リリースプロセスのボトルネック

バージョン管理

さまざまなプロジェクトのバージョン管理を処理するのは、特に依存関係の層が複数ある場合には困難です。

解放

プロジェクトが分割されていたため、リリースの追跡が複雑で、異なるプロジェクトのリリースを管理する必要がありました。

プロジェクトが異なるリポジトリに分割されていたため、リリース プロセスを自動化することは不可能でした。

そしてもちろん、継続的デリバリーはこの時点では考えられませんでした。

考えられる解決策?

インスピレーションを求めて周囲を見回すと、モノ リポジトリ アーキテクチャが私たちが欠けていた中心的な部分であるようです。 そうすれば、より良い開発プロセスが可能になります。 このアーキテクチャを中心に構築されたツールがあり、不足している部分 (リリース、自動化、バージョン管理など) を実現するのに役立ちます。

しかし、mono リポジトリとは何でしょうか?

モノラル リポジトリの核心は、他のすべての関連プロジェクト (アプリケーション、ライブラリ、ツール) を XNUMX つのフォルダー/git プロジェクトの下にカプセル化するプロジェクトです。 これにより、より優れた依存関係管理、ツールの均一化 (コード スタイルやタイプスクリプト構成など)、一元化された継続的インテグレーション、統合テスト、使用されるパッケージの統一バージョン (React など) が可能になります。

これはかなり不可知的なシステムであるため、いくつかの機能は私たちが見つけて実装する必要がありました。 うまくいけば、ビルド (CI に役立つシーケンシャル ビルド)、バージョニング、変更ログの生成にオーケストレーションを追加するのに役立つ、素晴らしいコミュニティ ツールがいくつかあり、リリース プロセスで欠けていたものを補うことができます。

デメリット

Mono リポジトリは、複数の開発者または開発者のチームが複数のプロジェクトに同時に取り組み、それらの間に依存関係がある状況で意味を持ちます。 ただし、セットアップ段階ではさらに複雑さが増します (特に 4 年の歴史があり、開発が活発に行われている、すでに稼働中のプロジェクトの場合)。 言及する価値があるのは、プロジェクトのディスク容量が大幅に大きくなるということです。 すべてのプロジェクトが同じフォルダーとすべての依存関係の下に置かれるようになりました。 どのテストが必須ですか? いつそれらをトリガーするか?

メリット

私たちの目標の時間、コスト、実現可能性を評価した結果、この移行によって期待される利点のいくつかが以下に挙げられます。

• 依存関係管理の改善: モノリポジトリを使用すると、異なるプロジェクト間の依存関係がすべて同じリポジトリに保存されるため、管理が容易になります。 これにより、糸のリンクや yalc、すべてのプロジェクトが正しいバージョンの依存関係を使用していることを簡単に確認できるようになります。
• コードの整理の向上: モノリポジトリを使用すると、すべてのプロジェクトとその依存関係が単一のリポジトリに保存されるため、コードの整理が容易になります。 さまざまなプロジェクトがどのように連携し、相互に依存しているかを理解しやすくなります。
• 開発者エクスペリエンスの向上: モノリポジトリを使用すると、開発者は異なるコードベースやリポジトリ間で切り替える必要がないため、複数のプロジェクトでの作業が容易になります。 また、すべてのコードが同じリポジトリに保存されるため、統合テストの実行も容易になります。
• 自動化の強化と継続的デリバリー: モノリポジトリを使用すると、コードのビルド、テスト、リリースなどのタスクを簡単に自動化できます。 これにより、リリース プロセスが合理化され、継続的デリバリーの実装が容易になります。
• 開発スピードの向上。 異なるチームが同じリポジトリで作業するため、リリースまで待って結果を検証する必要がなくなり、統合が加速します。

まとめ

全体として、モノリポジトリ構造の実装は、開発プロセスを改善し、リリース プロセスを合理化し、開発者のエクスペリエンスを向上させるのに役立ちます。

このシリーズの次回のブログ投稿では、この大規模な移行プロジェクトがどのように実施されたか、使用したツール、行った選択、結果などについて説明します。 パート 2: ツールをお楽しみに!

---

バレンティン・デ・アルメイダ
開発者エクスペリエンスとコア技術 – Ledger Live

• SEO を活用したコンテンツと PR 配信。 今日増幅されます。
• PlatoData.Network 垂直生成 Ai。 自分自身に力を与えましょう。 こちらからアクセスしてください。
• プラトアイストリーム。 Web3 インテリジェンス。 知識増幅。 こちらからアクセスしてください。
• プラトンESG。 カーボン、 クリーンテック、 エネルギー、 環境、 太陽、 廃棄物管理。 こちらからアクセスしてください。
• プラトンヘルス。 バイオテクノロジーと臨床試験のインテリジェンス。 こちらからアクセスしてください。
• 情報源： https://www.ledger.com/blog/ledger-live-monorepo-project-part-1-problematics-make-it-pain