単一のリポジトリからマルチレポ、モノレポ、マルチモノペロまで

このプロジェクトの進化は、多くのソフトウェア開発の旅を反映しています。シンプルで開始し、複雑さの高まりに適応します。当初、単一のリポジトリ内の大規模なモノリシックアプリケーションであり、建築リファクタリングとリポジトリ管理の複数の段階を通じて進化しました。

ステージ1：単一のリポジトリのシンプルさ

Leoloso/POPプロジェクトは、単一のリポジトリのテーマとプラグインを組み合わせたWordPressサイトとして始まりました。これにより、開発の最初の容易さが提供されましたが、同様の機能を備えたより多くのサイトが追加されたため、すぐに扱いにくくなりました。リポジトリは約10のサイトを含むようになり、メンテナンスの悪夢を作成しました。複数のサイトで文字列を検索して交換することは、非常に非効率的であることが判明しました。

ステージ2：マルチレポジトリチャレンジ

スケーラビリティの問題に対処するために、アプリケーションは作曲家が管理する独立したPHPパッケージにリファクタリングされました。これにより、パッケージごとに1つのリポジトリ、マルチレポジット構造への移行が必要でした。コードの再利用性とより良いアーキテクチャを促進する一方で、200を超えるリポジトリを管理することは非常に負担となりました。バージョンの依存関係と、多数のリポジトリにわたるプルリクエストの調整は、非常に複雑であることが証明されました。集中管理システムの欠如は、効率的な開発を妨げました。

ステージ3：モノレポの効率

ソリューションは、すべてのパッケージをホストする単一のリポジトリです。この合理化されたバージョン制御により、同時リリースと簡素化されたプルリクエストが可能になりました。ただし、Packagistはパッケージパブリッシングに個別のリポジトリを必要とするため、2つの広範なアプローチが採用されました。開発用のモノレポと配布用の個別のリポジトリです。これには、Monorepoビルダーツールを使用して処理されたモノレポを「分割」するプロセスが必要でした。この段階は、特にリファクタリング中に開発速度を大幅に改善しました。カスタマイズされたGitHubアクションを介して複数のWordPressプラグインを同時にリリースする機能ワークフローにより、効率がさらに向上しました。

その利点にもかかわらず、モノレポは制限を提示しました。すべてのパッケージに単一のライセンスを実施し、大規模な問題ボードの管理、コードの変更がなくてもパッケージの独立バージョンです。

ステージ4：マルチモノポーソリューション

パブリックコードとプライベートコードの両方を管理する必要性は、マルチモノポーアーキテクチャの採用につながりました。 Public Monorepo（Leoloso/POP）は上流のリポジトリとして機能し、プライベートモノレポ（Leoloso/graphqlapi-pro）は下流リポジトリとして機能し、Public MonorepoをGitサブモジュールとして組み込んでいます。これにより、プライベートリポジトリはパブリックコードベースにアクセスして拡張でき、単一の適応されたワークフローを使用して、パブリックプラグインバージョンとプライベートプラグインバージョンの両方の生成を可能にします。

ただし、このアプローチは複雑さをもたらします。ダウンストリームリポジトリは、サブモジュールを明示的にチェックアウトする必要があり、ワークフローを慎重に管理し、上流のリポジトリの変更を潜在的に破壊する必要があります。これには、意図しない結果を防ぐために、慎重なコードレビューと通信が必要です。

結論：進行中の旅

このプロジェクトのリポジトリ構造の進化は、変化するニーズに適応することの重要性を強調しています。各段階は利点と短所を提供し、最終的にはプロジェクトの要件を現在満たしているマルチモノポーセットアップにつながりました。ただし、将来のニーズには、リポジトリ管理戦略におけるさらなる反復が必要になる場合があります。 「最良の」アプローチは、ソフトウェア開発とリポジトリ管理の反復性を強調し、コンテキスト依存性のままです。

以上が単一のリポジトリからマルチレポ、モノレポ、マルチモノペロまでの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。