Mavenアーティファクトの解放の自動化

Question

多数のMavenアーティファクト（内部的に生成されたアーティファクトも外部のものも含む）のプロジェクトでは、製品リリース全体の一部として、内部的に制御されるアーティファクトのリリースを自動化する方法について説明します。

この問題については、JenkinsとMavenリリースプラグインを使用します。したがって、単一のアーティファクトを解放する操作は自動化されます（ただし、プロセスを開始する操作は手動です）。しかし、リリース中に変更されたアーティファクトをすべて解放するプロセスは自動化されていません（つまり、アーティファクトのリリースを手動で開始する必要があります）。問題の一部は、リリースが終わるまでほとんど何もリリースされていないことです。すべてがSHAPSHOTに残ります。私たちには膨大な数のコンポーネントだけでなく、多数のコンポーネントに依存する多数のアプリケーション/サービス（30以上）があります。したがって、コンポーネントを選択して解放する場合だけでなく、従属階層をリリースする必要があります（つまり、下から開始し、他のコンポーネントを使用しないコンポーネントを解放してから、すべてのアプリケーション/サービスがリリースされました）。

大部分は、外部アーティファクト依存のバージョンと内部コンポーネントの依存関係を制御する2つの共通の親のポームを使用することにも注意してください。コンポーネントやアプリケーション用のpomファイルの中にはこれを上書きするものもありますが、これは例外です（またはそうすべきです）。したがって、内部アーティファクトがリリースされると、対応する親依存関係のバージョンも更新されます。

製品にはリリース番号がありますが、さまざまなpomファイルは技術的にこのバージョン番号を共有していません。これは厳密には当てはまりませんが、ソフトウェアの一部が終了するように設定されているという考え方は、将来更新されないため、現時点で限定された数のアーティファクトバージョンが製品のバージョンと一致しますが、最終的にはそうではありません。

このプロセスを自動化する方法についてのご意見は、大変ありがたく思います。また、私が記述したことがソフトウェアを管理する狂気のように思えるなら、コメントを提供してください。ありがとうございました。

Answer 1

Maven Versions pluginを使用すると、プロジェクトのバージョンを正式化できる場合があります。

たとえば、次のリリースを使用すると、プロジェクトの最下位レベルをリリースし、リリースされたバージョンをより迅速に依存関係に持ち込むことができます。

必要に応じてコンポーネントを公開し、正式リリースされた「最新の」バージョンにプロジェクトを移行する場合は、use-next-versionsの目標を使用するスコープもあります。