Git プロジェクトの内部依存関係を管理しますか?

Git プロジェクトの内部依存関係を管理しますか?

複数のコンポーネントを持つ Git プロジェクトの管理について基本的な質問があります。私が言及しているプロジェクトの構造は次のとおりです。

project-name
├── cli
├── api
├── webapp
├── docker-compose.yaml
├── README.md
├── LICENCE

私の目標は、保守性とコードの再利用を優先する構造にすることです。そのため、コア機能はすべて Python のコマンド ライン インターフェイス (cli) に組み込まれています。また、REST API も構築しており、コードを書き換えずにバックグラウンドで cli を使用できるようにすることが目標です。

私の最初の質問は次のとおりです。これは良いアプローチでしょうか? 私は AWS など、API ベースの CLI を多数使用しました (私のアプローチとは逆)。また、ffmpeg など、CLI ベースの API も使用しました。そのため、私のケースでは、上で説明した方法を採用するのが理にかなっているかどうかはわかりません。

現在、API と CLI をリンクするには 2 つのアプローチを考えていますが、どちらが最も適切かわかりません。

  • アプローチ A: プロジェクト内の相対パスを使用して、API から CLI を直接呼び出します。ただし、これは CLI が常に API と一緒に出荷される必要があることを意味しますか?
  • アプローチ B: CLI を Python パッケージに別途ビルドしてリポジトリに公開し、それを API の要件として使用します。これは私にとっては「よりクリーン」に見えますが、パッケージを再度ビルドして公開する必要があるため、CLI で行った改善がすぐには確認できないことを意味します。

2番目の質問は次のとおりです。API で CLI を参照する適切な方法はどれですか? (または他の方法はありますか?)

前もって感謝します!

答え1

いいえ、ここには多くの問題があります。

  • API は CLI を使用しないでください。CLI は API を使用する必要があります。
  • 1つのリポジトリにcli/app/webappを入れることはできますが、これは悪い設計だと考えられています。「モノレポ」通常は、Web アプリケーションと CLI の両方が API を呼び出す 3 つの異なるリポジトリが必要になります。1 つの Dockerfile ではほとんど意味がないため、この方法の方が適しています。CLI をパッケージ化しているのか、それとも Web アプリケーションをパッケージ化しているのか? CLI と Web アプリケーションの両方に Dockerfile があることを期待します。
  • モノレポよりもマイクロレポを使用する利点は、主にツールにあります。ツールは、これらの機能に対してはるかに優れたサポートを提供します。
  • マイクロリポジトリを使用すると、CLI と Web アプリケーションは API とは別にバージョン管理されるようになります。これは常に望ましいことです。たとえば、2 つの異なるバージョンの API を同時に使用しながら、Web アプリケーションまたは CLI の 2 つのバージョンを開発できます。CLI と Web アプリケーションから API をプルすると、必要な他の外部依存関係と同じように機能します。

関連情報