2

私は、build.gradle ファイルをセマンティック バージョンを使用するように変換するイニシアチブの真っ最中です。Gradle の使用に加えて、Git も使用し、Gitflow ワークフローに従っています。Jenkins は、プロジェクトのビルドに使用されます。

リリースされたアーティファクトのバージョンは、MAJOR.MINOR.PATCH 形式に従います。build.gradle ファイルで依存関係を宣言する場合、10.0.+ などの動的バージョンを使用します (つまり、最新の 10.0.PATCH バージョンを使用します)。

アーティファクトを Release Candidates リポジトリから Nexus の Releases リポジトリに昇格させます。リポジトリのポリシーは「リリース」に設定されています。製品の複雑さ (200 以上のプロジェクト、多くのアップストリームとダウンストリームの依存関係がある) のため、Jenkins で利用できるプロモーション プラグインの多くは不十分なようです。アーティファクトの名前を変更し (10.0.0-rc.1-abcdefg は 10.0.0 になります)、正しい Nexus リポジトリにアップロードする方法として、Jenkins にマスター ブランチを構築させることを考えていました。

アップストリームの依存関係でパッチのバージョンが増加している状況を処理する方法がわかりません。ダウンストリーム プロジェクト (WAR) は Jenkins によって再構築され、新しい JAR がバンドルされますが、ダウンストリーム プロジェクトのバージョンは変更されません。Nexus にアップロードしようとすると、同じバージョンを持つことができるアーティファクトは 1 つだけであるため失敗します。

次に例を示します。

  • Releases Nexus リポジトリには、10.0.0 でバージョン管理されたアップストリーム API と 10.0.0 でバージョン管理されたダウンストリーム プロジェクトがあります。
  • ダウンストリーム プロジェクトはアップストリーム API の 10.0.+ に依存します
  • アップストリーム-api.jar は、ダウンストリーム-project.war ファイルにバンドルされています
  • 2 つの成果物は、製品のリリース X の一部としてデプロイされます
  • ホットフィックス ブランチがマスターにマージされると、upstream-api のバージョンが 10.0.1 に変更されました
  • この修正は、デプロイされると、製品が Release X' になることを意味します。
  • ダウンストリーム プロジェクトは 10.0.0 のままですが、アップストリームの依存関係の変更により再構築されます
  • Jenkins は、downstream-project-10.0.0.war が既に存在するため、Nexus へのアップロードに失敗します

古いアーティファクトを新しいアーティファクトに置き換えることもできますが、その場合、Release X は Nexus のアーティファクトから展開できなくなります (たとえば、ロールバックの場合、または古いリリースの問題を複製する必要がある場合)。

これは通常どのように処理されますか?

4

1 に答える 1

0

これは通常どのように処理されますか?

ここには普遍的な答えはありません。これらが最も「一般的な」可能性であると思います。

  • リリースと共に依存関係を配布せず、10.0.+. その場合、少なくともユーザーが許容できる限り、ソフトウェアが実際にどの10.0.x バージョンでも動作することが前提となります。これは通常、Linux ディストリビューションのソースまたはパッケージ システムで配布されるフリー ソフトウェアで発生します。依存関係のバージョン宣言は、依存関係に必要な改善がある場合、つまり変更が非常に重要であり、ユーザーが以前のバージョンを容認しない場合にのみ更新されます。

  • 依存関係をリリースと共に配布し、次のいずれかを行います。

    • 元のコードのメイン/セマンティック バージョン番号に加えてビルド番号を使用します (例: 1.3.4-b3)。私が間違っていなければ、これは多くの場合、プロプライエタリな Windows ソフトウェアに対して行われています。
    • 依存関係が変更されたときにメイン/セマンティック バージョン番号を増やし、依存関係の要件を明示的にします。

この問題に関するいくつかの一般的な考え

10.0.+中心的な問題は、動的な依存関係の宣言、つまりバージョンの宣言だと思います。この宣言で述べていることは、リリースがどの10.0.x バージョンでも同じように機能するということです。

  • その場合、つまり、依存関係のパッチによって修正されたバグがリリースに影響を与えないことが保証されている場合は、機能が変更されないため、リリースを再構築するべきではありません。依存関係のバージョンは問題ではありません。リリースは古い依存関係のバージョンのままにすることができます。

  • ただし、上流のバグ修正は下流のプロジェクトにも影響を与える可能性があります。つまり、リリースの機能に影響します。その場合、「新しい」依存関係を で明示的にする必要がありますbuild.gradle。これはリリース アーティファクトの変更であるため、新しいリリース バージョンが予定されています。

于 2015-07-01T19:57:03.123 に答える