9

現在、マルチモジュール Maven プロジェクトの Maven ビルドの最適化に取り組んでいます。プロジェクトは、約 90 の Maven モジュールで構成されています。一般に、コアを構成するいくつかの分野横断的なライブラリがあり、アプリケーション全体を構成する約 15 の「アプリケーション モジュール」があります (その後、WAR としてデプロイされます)。

一般に、プロジェクト全体のメジャー バージョンは「2.5」であるため、新しいメジャー リリースが完了すると、すべての「アプリケーション モジュール」は同じバージョン「2.5.0」になります。ここまでは順調ですね。

モジュールに修正または改善が必要なバグがある場合、その「アプリケーション モジュール」の新しいバージョンをリリースする必要があります。たとえば、モジュール A のバグが修正された場合、A.jar はバージョン「2.5.1」である必要がありますが、残りは「2.5.0」のままです。

親 (2.5.0-SNAPSHOT - モジュール A (2.5.1-SNAPSHOT) - モジュール B (2.5.0-SNAPSHOT) - モジュール C (2.5.2-SNAPSHOT) - 戦争 (2.5.3-SNAPSHOT) <-- 3最後に、C には 2 回の再リリースがあり、A には 1 回の再リリースがあり、簡単にするためにモジュールがリリースされるたびにリリースされたためです。

1 つのモジュールをリリースした後に各アーティファクトの依存バージョンを更新する必要がないように、マスター pom でアーティファクト バージョンを管理することにしました。

そのため、更新された「アプリケーション モジュール」の準備ができたら、maven リリース プラグインを使用してそのモジュールのリリースを実行します (プロジェクト全体ではなく、1 つのモジュールをリリースします)。したがって、モジュール A をバージョン 2.5.4 でリリースするとします。その結果、A.jar がバージョン 2.5.4 としてデプロイされ、モジュール コードが 2.5.5-SNAPSHOT に更新されて終了します。

これが完了したら、マスター pom のバージョンを更新する必要があるため、すべてのモジュールは引き続き正しいバージョンを参照します。

マスター pom の依存関係管理セクションのおかげで、War モジュールをビルドすると、モジュール A の新しいバージョンが自動的に取得されます。

すべてのモジュールがリリースされるとすぐに、Web アプリケーションの新しいバージョンをリリースする必要があります。これには、変更されていないすべてのモジュールと、リリースされたばかりのモジュールが含まれている必要があります。どうすればいいのか、現在悩んでいます。親の poms バージョンに依存している場合、リリースには SNAPSHOT バージョン (1 つのバージョンの増分が高すぎる) が含まれますが、これは私とリリース プラグインでは許可されません。

このジレンマの最善の解決策は何でしょうか?

依存関係の管理を別の pom にアウトソーシングし、それを「インポート」スコープを使用してマスター poms の dependencyManagement にインポートするという 1 つのアイデアがありました。

この種のシナリオはばかげたアイデアですか? このような大規模なマルチモジュール アプリケーションの開発と保守に代わる方法はありますか? アプリケーションが大きく、クライアント アプリケーションが更新されたモジュール バージョンをロードする必要があるため、プロジェクト全体でリリース プラグインを使用してすべてのバージョンを単純に同期することはできません。一部のお客様は接続が非常に遅いため、毎回すべてのモジュールをロールアウトすると非常に不満を感じます。

助けていただければ幸いです。

クリス

4

3 に答える 3

2

まず、バージョン番号は依存関係の管理には重要ですが、完全に恣意的であることを理解することが重要です。少なくとも、バージョン番号の形式は任意です (そうです、私はMaven バージョン範囲 の構文を知っていますが、誰も使用しているとは聞いたことがありません)。一部の OSS プロジェクトでは、「従来の」バージョン番号を完全に避け、SVN リポジトリのバージョンまたは日付のみをバージョン管理に使用しています。

1 つのオプションは、「プロジェクト全体」のバージョンを持たず、各コンポーネントに異なるバージョン番号を持たせることです。これは完全に受け入れられる解決策だと思います。

別の解決策は、スナップショットの依存関係を使用してリリースすることです。これを行うことは「想定」されていませんが、スナップショット バージョンをハード コーディングすることを妨げるものは何もありません (これは非常に冗長で、タイムスタンプが付けられています)。とにかく、繰り返し不可能なビルドの亡霊以外には何もありません.

すべてのコンポーネントのバージョン番号を同じにする必要がある場合は、プロジェクト バージョンのマイナー コンポーネントにビルド番号を組み込むことをお勧めします。

このアプローチでは、次の質問で説明されているように、バージョン内の増分リリースを区別するためにMaven ビルド番号プラグインを活用します: Buildnumber-maven-plugin でプロジェクト バージョンを設定できますか? .

これは、ビルド サーバー (またはビルド エンジニア) のみが使用する「最終リリース」プロファイルでのみ行うことに注意してください。

バージョン番号プラグインもここであなたの友達です。

最終的なリリース ワークフローは次のようになります。

  1. バージョンから始め2.5.5-SNAPSHOTます。
  2. mvn versions:set -DnewVersion 2.5.5.
  3. リリースをコミットしてタグを付けます (またはブランチを作成します - ここに戦略が何であれ)。
  4. mvn deploy -Preleaseこれにより、アーティファクトにビルド番号を追加する「リリース プロファイル」がアクティブになりますfinalName。
  5. mvn versions:set -DnewVersion 2.5.5-SNAPSHOT.
  6. 「リリース後」バージョンをコミットします。

本当に「メジャーな」リリースになったら、バージョン 2.5.6、2.6.0 などにインクリメントします。

幸運を！

于 2012-10-11T17:45:22.547 に答える
1

さて、私は私の問題の解決策を思いつきました。小さなリリース プラグイン パッチと Jenkins プラグインを組み合わせたもので、必要な非常に強力なコマンドライン構成を処理します。

リリース プロセスの説明: https://dev.c-ware.de/confluence/display/PUBLIC/Releasing+modules+of+a+multi-module+project+with+independent+version+numbers

Jenkins プラグインの説明: https://dev.c-ware.de/confluence/display/PUBLIC/Developing+a+Jenkins+Plugin+for+the+Maven+Release+Plugin

プラグインのコード: https://github.com/chrisdutz/jenkins-release-plugin

于 2013-09-29T18:01:18.923 に答える
0

昨夜、質問でキャッチしたビルドには別の大きな問題があることに気付きました。モジュールには相互に deps があり、リリース プラグインでは処理されません。これらの SNAPSHOT 依存関係により、プラグインが失敗します (これは良いことです)。

だから私はちょうど私の問題を解決するかもしれない別のアイデアを持っていました.devとrelのバージョンを定義するdependencyManagementセクションを含む2つのmaven pomアーティファクト「versions-dev」と「versions-rel」を作成します。私のマスターポンでは、「開発」（デフォルトでアクティブ）と手動でアクティブにする必要がある「リリース」の2つのプロファイルを作成します。これらのプロファイルには、dependencyManagement セクションが含まれており、スコープ「インポート」を使用して、対応する version-pom アーティファクトの依存関係管理をそれぞれインポートします。

リリースの場合、次の手順を実行する必要があります。 - versions-rel と versions-dev を新しいバージョンに更新します。- コミット - タグ - release プラグインの release:perform ターゲットを実行します

問題を引き起こす可能性のあることがまだ 1 つあります。すべてのモジュールが変更されているが、新しいリリースに含める必要があるのは 1 つだけであると仮定すると、このアプローチでは、不要なモジュールも含めて、すべてのモジュールを再デプロイすることになります。リリース。これにより、変更されたバージョンが、以前にリリースされたバージョンと同じバージョンでデプロイされる可能性があります。メインプロジェクトをリリースせず、個々のモジュールのみをリリースすることで、これを回避できました。ただし、まだデプロイされていないバージョンのみをデプロイすることができれば、リリース プロセスがはるかに簡単になります。

提案、異議、忘れたことはありますか?

クリス

于 2012-10-12T07:05:39.857 に答える