依存関係管理ツール (Maven 2 など) の使用を想定して、プロジェクト内で主要な依存関係のアップグレードを処理するためのベスト プラクティスを探しています。
具体的には、次のことに興味があります。
あなた自身の経験や、あなたが出会った/役に立つとわかった記事/論文は大歓迎です.
編集: 依存関係のバージョン番号の更新は簡単です。依存関係の変更（非推奨、削除、パラメーター/戻り値の型の変更など）に基づいて、必要な変更にどのように取り組むかをもっと探しています。また、将来的にこれらの変更を容易にする良い方法がある場合は、依存関係を最新の状態に保つことで、変更を常に把握し、「より安全な x 2.1」機能を取得するためだけに多くの時間を無駄にすることを防ぐことができます。 '。
依存関係の変更を処理するためのグッドプラクティスは、アプリケーション設計のグッドプラクティスと同じです。アーキテクチャを階層化し、各依存関係でのコードの広範な結合を最小限に抑えて、変更を分離しておく必要があります。これにより、依存関係をアップグレードしても、アプリケーションのすべての部分が破損することはありません。インターフェイスへのコードを作成し、ビジネスロジックをインフラストラクチャコードから分離します。
マイナーアップグレード（依存関係のポイントリリースのアップグレード）の場合、APIの変更による障害を検出するための包括的な単体テストのセットがあると役立ちます。これが、表面上は常に機能しているように見える些細なテストを作成するのに役立つことがある大きな理由の1つです。この例は、単純なクエリを実行するための単純なJDBC単体テストの作成です。これは、データベースのアップグレード後にJDBCドライバーの実行時の問題を検出するまでは、労力の無駄のように思われます（これは私に起こりました）。
大規模な変更（Springなどの互換性のないバージョンのフレームワーク間のアップグレードなど）の場合、自動化された機能テストまたは統合テストがある場合、または少なくともQA担当者が高レベルの機能を検証するために実行できる機能仕様がある場合に役立ちます。アップグレードするフレームワークAPIが十分に異なり、コードを大幅に変更する必要がある場合、単体テストは関連性がなくなる可能性があります。
あるバージョンの依存関係から別の互換性のないバージョンへの移行を管理する実際の戦術的な部分は、実際に何をしているかによって異なります。成熟したライブラリは、ある種の移行パスを提供し、うまくいけば、すべてを書き直す必要はありません。フレームワークのアップグレードに関連するコードの変更を、新機能の実装に関連する変更から分離することをお勧めします。このようにして、何かが壊れた場合、それはフレームワークのアップグレードに関係していることがわかり、新しい機能の実装中に壊れたものではありません。
これを非常に難しくしている理由の1つは、実行時にJVMに特定の依存関係のバージョンを1つしか持てないため、すべてのコードを一度に更新する必要があることです。OSGiは、同じ中で実行されているさまざまなOSGiバンドルがさまざまな依存関係バージョンに依存できるようにすることでこの特定の問題に対処するため、実行時にさまざまな依存関係バージョンに依存できます。これは、Eclipseが他のプラグインを壊すことなくプラグインの依存関係を管理する方法です。
私の経験では、依存関係のアップグレードは、依存関係が所有する必要な機能のために、自分のコードに直接影響する依存関係のバグの修正として、新しいJavaリリースをサポートするため、またはコードを特定のコードに準拠させるために実装されます。標準（セキュリティに影響する依存関係に関して）。コードがこれらの必要な領域のいずれにも当てはまらない場合は、わざわざ最新の状態に保つことはしませんが、リリースごとに更新すると実際にアプリケーションにバグが発生する可能性があるため、必要に応じて更新するだけです。
ベストプラクティスは、サイクルのアプリケーションの本番環境を終了し、安定したビルドとしてリリースし、次の開発イテレーションで依存関係を手動で更新することから始まることを常に知っています。親POMでバージョンを一元化すると、依存関係のバージョン変更が最小限に抑えられ、拡張性が向上します。Mavenを使用していると仮定します。
<dependency>
<groupId>your.dep.group</groupId>
<artifactId>your-artifact-id</artifactId>
<version>${desiredVersion}</version>
</dependency>