私が働いている会社には、Go で書かれたいくつかのバックエンド システムがあり、コードの一部はそれらの間で共有されています。バックエンド システムは個別に展開する必要があり、場合によっては異なるマシンに展開する必要があります。これらのプロジェクトはすべてまだ活発に開発されており、かなり頻繁に変更されています。
私たちは、git リポジトリとそれらの間の依存関係を管理する良い方法を見つけようとしています。
現時点では、共有コード用のリポジトリが 1 つあります。これをバックエンド共有と呼びましょう。次に、バックエンド システムごとに個別のリポジトリを用意します。それらを backend1 および backend2 と呼びましょう。次に、各バックエンドは backend-shared に対する Godep 依存関係を持ちます。
私が理解している限り、Golang での依存関係管理の推奨される方法は、すべての依存関係が /vendor ディレクトリにコピーされ、バージョン管理にチェックインする必要があるベンダーによるものです。このようにして、すべての依存関係が特定のバージョンにロックされます。
これは、外部の依存関係に対しては問題なく機能しますが、バックエンド共有の内部依存関係については、開発者が特定のバックエンド システムとバックエンド共有システムの両方に同時に変更を加える必要があることは珍しいことではないため、非常に面倒になります。
現在、開発者の GOPATH に存在する backend-shared に変更が加えられた場合、その変更は backend1 内 (GOPATH でも) には表示されません。 /vendor ディレクトリ。
したがって、backend-shared の新しいバージョンをコピーするために backend1 を再ベンダー化するか、/vendor ディレクトリから backend-shared を一時的に削除して、インポートが GOPATH 内のバージョンを指すようにする必要があります。 . これらのオプションは両方とも潜在的に汚いと感じており、それらがGoの使用方法であるかどうかはわかりません.
私の質問は、現在のリポジトリを維持し、一度に複数のプロジェクトの開発を簡素化するためのより良い方法があるかどうかです?
それとも、すべてのリポジトリを単一のリポジトリに結合する必要がありますか? 現在、依存関係の観点からバックエンド 1 とバックエンド 2 が分離されていても、それらの開発ライフサイクルがかなり絡み合っていることを考えると?
backend1、backend2、および backend-shared を含む単一のリポジトリから始めなかった主な理由は、backend1 と backend2 を別々にデプロイする必要があるため、それらのコードも物理的に分離したかったからです。