38

私のチームは機能ブランチを使用して新しい機能を実装し、ユーザーが使用できるようにスナップショット ビルドをリモート リポジトリに継続的にデプロイしています。したがって、「デプロイ」は実際には「リモート Maven リポジトリへの配布」を意味するだけです。現在、次の理由により、マスター ブランチの継続的インテグレーション ビルドのみを実行しており、フィーチャー ブランチでは実行していません。Maven を使用してプロジェクトをビルドし、JavaDoc とソースを JAR と共に配布しています。

私の計画は、各機能ブランチのビルドに分類子を追加することであり、次のような成果物を作成およびデプロイするときに使用されることを期待していました。

  • ブランチ: マスター
  • 分類子: なし

  • アーティファクト: foo-${version}.jar、foo-${version}-sources.jar、foo-${version}-javadoc.jar

  • ブランチ: 機能-X

  • 分類子: myfeature
  • アーティファクト: foo-${version}-feature.jar、foo-${version}-sources-feature.jar、foo-${version}-javadoc-feature.jar

アーティファクトの正確な名前はあまり気にしません。機能ブランチ用にメイン、ソース、および JavaDoc アーティファクトを個別に必要とするだけです。JavaDoc プラグインもソース プラグインも分類子が構成されているとは見なさないため、マスター ビルド用に作成されたアーティファクトを効果的に上書きします。

おそらく問題は解決しますが、artifactId を変更したくはありません。機能ブランチと Maven との継続的統合にどのようにアプローチしますか?

4

4 に答える 4

10

バージョンコンポーネントとの関連性が高いため、バージョンコンポーネントにブランチ修飾子を追加することをお勧めします。これにより、メインブランチと一緒にこれらのバージョンへのスナップショットの依存関係も可​​能になります。

于 2012-07-10T12:51:13.707 に答える
9

ブランチを表す適切なバージョンと、次のようなバージョンを使用することをお勧めします。

1.0.0-マスターのスナップショット

と

1.0.0-F1機能F1のスナップショット

等

これにより、リリース1.0.0から機能ブランチが作成されたインジケータも提供されます。

于 2012-07-10T13:20:38.050 に答える
5

アーティファクトの Maven 座標を変更する代わりに、maven-branch-extensionを使用して、機能ブランチごとに個別の SNAPSHOT 名前空間を効果的に作成できます。プロジェクトページからの引用：

機能ブランチでバージョン番号を変更する代わりに、リポジトリを変更します。各機能は、ブランチ名に基づいて、機能ブランチ専用のリモート リポジトリ内のサブディレクトリにデプロイされます。アーティファクトが上書きされるリスクはありません。バージョン番号は変更されません。Git を使用したブランチとマージはシンプルなままです (意図されていたように!)。

拡張機能は現在の Git ブランチを取得し、リポジトリの URL のプロパティを解決して、アーティファクトを正しく保存および取得できるようにします。また、ローカル リポジトリへのアーティファクトのキャッシュとフェッチを管理し、フィーチャー ブランチから作業するときにアーティファクトが存在する場合は、フィーチャー ブランチ リポジトリからアーティファクトが取得されるようにします。

この利点は、SNAPSHOT 依存関係の外部ユーザーが、トピック ブランチに関する内部作業から完全に分離されていることです。

于 2017-04-11T17:34:16.287 に答える