web-dev-qa-db-ja.com

マイクロサービス：多くのマイクロサービスのソースコードを格納する方法？

現在、1つのプロジェクトに対して20マイクロサービスがあります。そして、すべてのマイクロサービスは個別のGITリポジトリに格納されます。その後、サービスの数はから200（以上）に増加します。

すべてのサービスには、単体テストと統合テストがあります。すべてのサービスはTeamCity（継続的統合サーバー）に組み込まれています。

質問：1つのプロジェクトの200マイクロサービスのソースコードを保存するにはどうすればよいですか？ 1つのリポジトリまたは別のリポジトリにありますか？

gitmicroservices
39
kazhuravlev

それらのマイクロサービスが密に結合されていない限り（それらの一部だけをダウンロードするのは意味がなく、それらのすべてでのみ作業する）、それらをそれぞれに保持します別のGitリポジトリをお勧めします。

しかし、親リポジトリでsubmoduleとしてそれらを参照して、いつでもそれらの状態を追跡できます。

19
VonC

gitサブモジュールとサブツリーにも独自の問題があります。 FacebookとGoogle？すべてのマイクロサービス用の単一のリポジトリを持っています。この問題に対する明確な答えはありませんが、リファクタリング、依存関係の管理、プロジェクトの設定などは、モノリポジトリからメリットを得ます。繰り返しになりますが、サービスのカップリングと、さまざまなチームがどのようにリポジトリとやり取りするかが、どちらかを選択するための鍵となります。

13
Oscar Perez

サブモジュールは使用していません。私たちが行ったことは分岐戦略です

すべてのマイクロサービスには、base_folderフォルダーの下に独自のフォルダーがあります。

リリースブランチがあります->現在1つのマスター（これにはすべてがあります）インターフェースブランチ->インターフェースがあります（これには、すべてのサービスのprotobuffer/grpcファイルなどのインターフェースのみがあります）。このブランチは常にマスターにマージされます

各サービスにはブランチ-> sprint_service_nameがあり、コードがプッシュされ（コードレビュー用）、マージリクエストがマスターブランチに作成されます。

コードフロー

新しいコンポーネントの場合

git checkout interfaces
git checkout -b sprint_service_name 
(create branch from interface branch)

既存のコンポーネントの場合

git checkout sprint_service_name
git fetch Origin interfaces
git merge Origin/interfaces (don't use git merge Origin interfaces !!)

（または上記の2つのステップではgit pull Originインターフェース）

こちらが開発者フローです

Push to sprint_service_name branch and create merge request to master branch
git Push Origin  sprint_service_name

分岐フロー

sprint_service_namexxx --> Merge Request --> master
sprint_interfaces -->  Merge Request --> Interfaces -->master
interfaces --> sprint_service_namexxx (by all, every day)

すべての一般的なパーツはインターフェースブランチにあります

（プライベートブランチはいくつでも持つことができますが、マスターをsprint_service_nameにマージしたり、マスターをインターフェイスにマージしたりしないでください。そうしないと、不要なファイルがブランチに存在します）

Pros各マイクロサービスには、コードとインターフェイスフォルダーのみがあります

短所

以下のフローが常に理想的に発生するとは限りません。

sprint_interfaces -->  Merge Request --> Interfaces -->master

もっと似ている

sprint_interfaces -->  Merge Request --> master

つまり、インターフェイスフォルダーをマスターから手動で取得し、インターフェイスブランチにマージする必要があります。しかし、これは規律の問題であり、何も壊していません

7
Alex Punnen

130以上のサービスを利用していた会社で働いていました。一部のサービスは外部APIに接続していました。つまり、私たちのエコシステムの外にありました。ただし、各サービスを独自のGITリポジトリに保存するだけを使用しました。 1つのBOMの下に、暗号化、ロギングなどのコモンズライブラリがありました。個別のリポジトリを作成すると、誤って相互に関連付けられたマイクロサービスを作成することができなくなります。それがアイデア全体の目標です。今後、必要に応じて、個々のサービスをさらに削減することができます。 130以上のマイクロサービスを使用することで、相互依存コードの問題が発生することはなく、他のサービスを気にすることなく展開がスムーズになりました。

0
nimesh makwana
  1. Githubにリポジトリを作成する
  2. ローカルマシン上のgit cloneリポジトリ
  3. リポジトリ内にプロジェクトを作成してコミット->リポジトリ内にプロジェクトをプッシュ
0
Obothlale

プロジェクトの規模が大きいか小さいかに関係なく、プロジェクト全体に対して1つのリポジトリのみが必要です。

こちら のほとんどのことを処理するプロジェクトを構築するための12 Factor Applicationを参照できます。

12 Factorアプリケーションのコンセプトは、多くのマイクロサービスを持つ大規模プロジェクト向けです。

0
freshPrince