私はマイクロ サービス アーキテクチャについて考えていて、人々が開発環境の優れたベスト プラクティスを持っているかどうか疑問に思っていました。
私の作業上の仮定は、各マイクロ サービスは、分離と展開の容易さのために独自の git リポジトリに存在するということです。また、各開発者は、作業中のレポのフォークを作成すると想定しています。
私が検討している問題は、複数のマイクロサービスを含む問題に取り組んでいる場合に発生します。たとえば、あるマイクロ サービスに影響を与える欠陥と、それが別のマイクロ サービスを適切に消費する方法があります。
n 個のプロジェクトが欠陥に関係していると仮定すると、n 個の git リポジトリをチェックアウトし、それらが連携するように構成する必要があります。それぞれに Vagratefile と Dockerfile がある場合、n 個の VM を実行することになります。理想的には、Vagrant VM は 1 つだけで、各サービスは同じ VM 内の新しい Docker インスタンスになります。
git サブモジュールを含むマスター リポジトリ/プロジェクトが機能する可能性があります。これに関する問題は、一般的なマスター リポジトリ/プロジェクトを作成すると、サブ モジュールが開発者のフォークではなくアップストリームを指すようになることです。
私は現在、いくつかの構成、vagrant、および fig を含むマスター プロジェクトがそのトリックを行う可能性があると考えています。現在、このアプローチを実装する 2 つの方法を検討しています。
- 構成にいくつかのデフォルトを指定します。つまり、project_1 は ../project_id に配置する必要があります。
- ユーザーの github アカウントに基づいてサブモジュールを作成するスクリプトを提供します。これにより、ユーザーのフォークのリモートと上流プロジェクトのリモートが作成されます。
他の誰かがこの問題を解決しましたか、または良いワークフローを持っていますか?