5

私は現在、2つのソリューションに約15のプロジェクトとデータベース用のスクリプトを含む1つのgitリポジトリがあるシナリオで、gitフローを使用してリリース管理を行う方法を理解しようとしています。

各ソリューションには基本的に、実行可能ファイルを生成する 1 つのプロジェクトと、DAL、SAP アクセス ラッパーなどの両方のソリューションで使用される基本機能を含む 10 以上のプロジェクトが含まれます。
ソリューション 1 は、ユーザー向けの UI を備えたアプリケーションです。
解決策 2 は Windows サービスです。
2 つのソリューションのリリースとデータベースは同期していません。これは、多くの場合、3 つのうち 1 つまたは 2 つだけがリリースされることを意味します。これにより、バージョン番号が異なります。たとえば、UI は頻繁にリリースされますが、サービスはめったにリリースされません。その中間のデータベース。したがって、UI はバージョン 2.1.15、サービス 2.1.1、およびデータベース 2.1.5 を持つことができます。

では、共有プロジェクトをどうするか? UI のバージョン番号を使用する必要がありますか?それともサービスのバージョン番号を使用する必要がありますか?
共有プロジェクトの 1 つを変更しても、両方のソリューションのリリースが自動的にトリガーされないという事実をどのように説明すればよいでしょうか? これは、実稼働環境に同じプロジェクトの 2 つの異なるバージョンが同時に含まれていることを意味します。これは何らかの方法でリポジトリに反映する必要があります。

私はここで少し迷っています。アドバイス、経験などをいただければ幸いです。
私はレポジトリとコード ベースをどのような方法でも自由に構築できます。それが役立つ場合は、追加のレポジトリを作成できます。

4

1 に答える 1

3

最初に、異なるバージョンのプロジェクトがある場合は (多少依存関係はありますが)、それらが異なるバージョンを持つのに十分なほど異なる場合は、必ずそれらを異なる git リポジトリに配置してください。

すべての製品が同じリポジトリにある場合、効率が悪いだけです。たとえば、あなたが UI に取り組んでいて、別の人がサービスに取り組んでいて、UI に小さな修正を加えた場合、あなたの作業をそれらとマージすると、サービスの変更も取得されます (気にしませんでした)。為に）。

15 個のプロジェクトのうち、関連が強すぎるものがある場合は、それらを同じリポジトリ (UI のコンポーネントなど) に保持できます。

さまざまなリポジトリができたので、それらの個別のリリースと個別のバージョン番号を簡単に管理できます。

ただし、注意したいのは互換性です。たとえば、バージョン 2.4.5 の UI は 2.1.7 ～ 2.2.9 の範囲のバージョンのサービスと互換性がある可能性があり、同様に、バージョン 2.1.10 のサービスは 2.4 の範囲のバージョンの UI と互換性がある可能性があります。 .3-2.4.8. ソフトウェア コンポーネントの各バージョンは、他のコンポーネントのバージョンとの互換性をチェックできる必要があります。

于 2013-01-15T11:07:50.987 に答える