複数のオープン ソース Java ライブラリを使用するプロジェクトに取り組んでいます。これらのライブラリのアップグレードが発表されたとき、私たちは保守的な戦略に従う傾向があります。
通常、新しいライブラリを入れてアプリケーション全体を徹底的にテストする時間がないため、この戦略に従います。(多くのソフトウェア開発チームと同様に、数か月前に約束した機能については、常に予定より遅れています。)
しかし、いくつかのパフォーマンスの改善と多数のバグ修正が通常ライブラリのアップグレードに伴うことを考えると、この戦略が賢明かどうか疑問に思うことがあります。(つまり、「予想もしていなかった方法で事態が好転するかもしれません...」)
プロジェクトでこれらの種類の決定を行うとき、どの基準を使用しますか?
重要:技術的負債は避けてください。
「壊れていない場合はアップグレードしない」というのは、ソフトウェアが壊れてしまい、誰も修正できないというクレイジーなポリシーです。
軽率でテストされていない変更は悪い考えですが、短期的には安く見えるため、技術的負債を蓄積するほど悪くはありません。
「夜間ビルド」プロセスを開始して、すべての変更を継続的にテストできるようにします。自分の変更だけでなく、依存しているパッケージも同様です。
継続的な統合プロセスができるまでは、インフラストラクチャのアップグレードを含む四半期ごとのメジャー リリースを行うことができます。
技術的負債を回避します。
私は次のことを行うのに十分な教訓を学びました。
編集:少なくとも同じくらい重要な項目をもう 1 つ追加したかったのですが、他の項目よりも重要かもしれません。
新しいバージョンがあるという理由だけでアップグレードしたくはありませんが、別の考慮事項があります。それは、古いバージョンの可用性です。オープンソース プロジェクトを構築しようとして、その問題に遭遇しました。
私は通常、ライブラリの新しいバージョンを無視するのは間違いだと思います (興味深い機能や改善点がないからです)。にアップグレードすることをお勧めします。
したがって、私のアドバイスは、新しいバージョンで何が変更されたかを注意深く確認し、その変更に多くのテストが必要かどうかを検討することです。
多くのテストが必要な場合は、ソフトウェアの次のリリース (メジャー バージョン) で新しいライブラリにアップグレードすることをお勧めします (v8.0 から v8.5 に移行する場合など)。こうなったら、他にも大きな変更があるのではないかと思うので、いろいろと検証していきます。
1 つの方法は、使用するオープン ソース ライブラリを独自のソース コード管理下に置くことです。次に、アップストリームの変更を次のリリース ブランチに定期的にマージするか、セキュリティ修正の場合はそれよりも早くマージし、自動テストを実行します。
つまり、社内で記述したコードのリリース サイクルの場合と同じ基準を使用して、アップストリームの変更を使用するかどうかを決定します。オープンソース開発者を仮想開発チームの一員と考えてください。とにかく、これは実際に当てはまります。それは、開発プラクティスの一部としてそれを認識することを選択するかどうかの問題です。
依存ライブラリでバージョンが大幅に遅れないようにすることを好みます。セキュリティまたはパフォーマンスの問題が判明していない限り、ほとんどのライブラリでは最長 1 年で問題ありません。 既知のセキュリティの問題があるライブラリは、更新する必要があります。
各ライブラリの最新バージョンを定期的にダウンロードし、それらを使用してアプリの単体テストを実行しています。合格した場合は、開発および統合環境でしばらく使用し、問題がないと確信したら QA にプッシュします。
上記の手順は、API が大幅に変更されていないことを前提としています。新しいライブラリ バージョンを使用するためだけに既存のコードをリファクタリングする必要がある場合、すべての賭けはオフです。(例: Axis 1x 対 2x) 次に、経営陣を巻き込んで、リソースの割り当てを決定する必要があります。このような変更は、通常、レガシー コードのメジャー リビジョンが計画されるまで変更されます。
いくつかの重要な質問:
上記の基準に従ってアップグレードが悪いように見えない限り、アップグレードを続行することをお勧めします。問題がある場合は、古いバージョンに戻します。