サードパーティのライブラリを最新の状態に保つ方法は？

10個のライブラリに依存するプロジェクトがあり、プロジェクトのトランク内では、これらのライブラリの任意のバージョンを自由に使用できるとしましょう。だから、私は最新バージョンから始めます。その後、これらのライブラリはそれぞれ月に1回（平均）更新されます。トランクを完全に最新の状態に保つには、ライブラリ参照を3日ごとに更新する必要があります。

これは明らかに多すぎる。通常、バージョン1.2.3はバージョン1.2.2のドロップイン代替品ですが、テストなしでは決してわかりません。単体テストでは十分ではありません。DB /ファイルエンジンの場合、古いバージョンで作成されたファイルで適切に動作することを確認する必要があります。GUIと関係がある場合は、すべてを視覚的に検査する必要があります。等々。

これをどのように処理しますか？いくつかの可能なアプローチ：

• 壊れていない場合は、修正しないでください。ライブラリベンダーが更新を発行する頻度に関係なく、アプリケーションで使用するときにライブラリに問題がなければ、ライブラリの現在のバージョンを使用してください。小さな増分変更は無駄です。
• 変更を小さく保つために頻繁に更新してください。いずれにせよいつか更新する必要があるため、いくつかのバージョンを飛び越えて潜在的な問題を蓄積させるのではなく、修正が容易なときに早期に問題に気付くように、頻繁に更新することをお勧めします。
• 間に何か。スイートスポットはありますか？

私はここでの答えの数に「あなたが必要でない限り更新しないでください」と言ってショックを受けました-そして実際にapp然としました-。私はそれをしました、そして、それは短期的には簡単ですが、それは長期的には地獄のように燃えます。頻繁に行われる小さな更新は、時折大きな更新よりもはるかに簡単に管理でき、新機能やバグ修正などのメリットをより早く得ることができます。

ライブラリの変更は、コードの変更よりもテストが多少難しいというこの考えを買いません。まったく同じです。コードベースに変更を加えているので、コミットする前に、リリースする前により深く検証する必要があります。ただし、コードを変更しているため、これを行うためのプロセスが既に必要です！

あなたが2〜4週間の反復で作業している場合、反復の直前よりも少しリラックスしたときに、開始後できるだけ早く実行されるように、反復タスクごとにライブラリを更新することをお勧めします期限、およびプロジェクトは変化を吸収するためのより多くの能力を持っています。誰か（またはペアプログラミングを行う場合はペア）に座って、どのライブラリが更新されたかを確認し、各ライブラリを持ち込んで再構築とテストを実行してみてください。おそらく、反復ごとに半日から1日の予算を立てます。物事が機能する場合は、変更をチェックインします（私たちが行っているように、ライブラリをソース管理に保持していると仮定しています。テストが完全に手動である場合よりも、自動化されたテストを使用する場合、これは明らかにはるかに簡単になります。

さて、問題は、更新が問題を起こした場合の対処方法です。それを修正するのに時間を費やしますか、それとも省略しますか？後者に傾くことをお勧めします。1時間以内に修正できる場合は修正しますが、更新に統合するのに多大な作業が必要な場合は、それを独自の開発タスクとして上げ、他の場合と同様に推定、優先順位付け、およびスケジュールします。可能性としては、非常に重要な修正または改善がもたらされない限り、優先度が低くなり、それを回避することはできません。しかし、次の反復更新日がくる頃には、問題がそれ自体で修正されたかもしれません。たとえそうでなくても、少なくとも今では、更新パスに障害があることがわかっているので、驚くことはありません。

その長さの反復を行っていない場合は、更新のために何らかのスタンドアロンのスケジュールを設定します-毎月より長くはありません。毎月のステータスレビューや建築委員会の会議など、他のプロジェクトリズムと結び付けることはできますか？給料日？ピザの夜？満月？いずれにせよ、従来のリリースサイクルよりもはるかに短いものを見つける必要があります。6〜18か月ごとに一度にすべてを更新しようとすると、苦痛を感じ、士気を低下させるためです。

言うまでもなく、リリース前に安定化ブランチを行う場合、このポリシーをそれらに適用しません。そこでは、重要な修正を得るためにライブラリを更新するだけです。

評価します。

• 最初に、そのライブラリに対して発生したバグを探し、それらが修正されたかどうかを確認します。
• 第二に、私たちが恩恵を受ける可能性のあるlibの他のバグ修正を探します（おそらく可能性のあるもの）。
• 第三に、lib / APIの改善点を探し、それを利用するためにコードを変更した場合の影響と、利益のトレードオフを調査します。私は過去に、新しい機能を実際に利用せずにライブラリをアップグレードすることが多すぎました。

次に、既存のライブラリにとどまることに対して、それらすべてを比較検討します。

常にテストします-できれば、ユニット/統合テストで大きなリグレッションが発生しないことを確認してください。

サードパーティライブラリの主な問題は、本番環境に移行する前に、更新するときにアプリケーションを再テストする必要があることです。そのため、ライブラリの更新が必要なバグが報告されていない限り、完全な品質保証サイクルを実行する時間ができるまでバグに手を触れないでください。

これは通常、新しいバージョンをリリースするときに行われます。

ただし、開発ブランチのライブラリを更新して自動的に更新できる連続ビルド用のテストスイートを用意することをお勧めします。これにより、破損したときに早期に発見できるため、プロジェクトにバグレポートを提出できます。

部分的に、svnベンダーブランチで説明されているように。ここで説明されている手順は、オープンソースのサードパーティライブラリを長期間使用し続け、ニーズに合わせて変更する場合に非常に役立ちます。

リリースの直前または直後に、プロジェクトのすべてのライブラリを更新することを検討します。ただし、10個または15個を超えるライブラリに依存している場合、これは手に負えない可能性があります。その場合、何らかの更新チェックメカニズムが大いに役立ちます。これの利点は、ライブラリのテストに専念する時間があり、ワンパスで問題を修正できることです。また、すべてのライブラリからの更新を常に追跡する必要はありません。更新があるかどうかを特定の日に確認するだけです。

また、devブランチでさえ、あらゆる種類の自動更新機能に反対します。ライブラリが自動的に更新されたために、プロジェクトの途中で作業を中断したり、他の何かに取って代わられたAPIを使用すると、減価償却の警告が突然表示されたりすると、イライラします。

あなたは、あなたがアップデートから本当に何を望んでいるのか尋ねなければなりませんか？ほとんどのセキュリティ修正は、実際には修正の形での簡単なパッチです。

• 任意のコードをバッファの未使用スペースにコピーできるエラーが1つ発生する
• 宙ぶらりんのポインター、または未定義ではあるが（むしろ）決定論的な動作をトリガーする何か
• ある種のDoSを許可するバグ
• 誤ってプライベートデータのスヌーピングを容易にするバグ
• 数学の失敗
• メンテナが触れるべきではないものに触れる（Debian SSLバグ、誰か？）

過去5年間でほとんどのCVEを調べてみると、オープンライブラリを使用している場合、それらを修正するパッチは通常非常に簡単です。

その後、実際にバグを修正しますが、おそらくそれは必要ですが、おそらくすでに自分で修正しています。壊れていない場合は、修正しないでください。

最後に、新しい機能があります。おそらく廃止された機能です。これらのリリースノートと差分を注意深く調べる必要があります。他の多くのものが依存しているAPIを壊しても、それらを使用できますか？はいの場合、それは手術の時間です..いいえの場合、チェリーはあなたが望むものを選んで先に進みます。

一部の人は私に反対するかもしれませんが、ソースコードなしでライブラリを使用することを拒否します。

ライブラリの種類、使用目的、コード内での普及度、アップグレードの実行にかかるコスト（時間と費用）などによって異なります。

理想的には、常に最新版を常に持っているはずですが、新しいバージョンに下位互換性がない場合はどうでしょうか？変更を慎重に処理できるようになるまで、将来のリリースのためにその更新を棚上げする必要がある場合があります。テストでは検証が困難な、動作に若干の変更（「メソッドYを呼び出す前にプロパティXを設定する必要がある、または遅いメモリリークが発生する」など）が発生する可能性があります。

一方、新しいバージョンには重大なセキュリティ修正が含まれている可能性があるため、同様に考慮する必要があります。

ショートバージョン：ケースバイケースでそれを取ります。

これはリリースのスケジュールに依存します。

しかし、私のアドバイスは、すべての開発者のマシンに一連のライブラリをインストールすることです。それを何かと呼びたいなら、それをゴールドスタンダードと考え、そのリリースのために開発を始めてください。

リリースが展開され、リリース後の段階になった場合にのみ、ライブラリ、バージョン、機能を再評価します。大幅な改善または新機能が提供されている場合は、次の開発サイクルの開始前にインストールしてください。

ソフトウェアを展開する前に修正する必要がある大きな問題またはバグがある場合にのみ、新しいバージョンをインストールしてください。

これは、いくつかのバージョンを見逃すことを意味しますが、アプリケーションの開発に集中できるようにするために、頭痛とバージョン管理の問題を軽減する必要があります。

Subversionの外観

この機能の優れている点は、必要なリビジョンを指定できることです。

多数のエクスターナルがある場合、更新が遅くなることに注意してください。

私は現在そのようなものを設定しています：

• アプリケーションの拡張ごとに1つのMercurialリポジトリ
• いくつかのサードパーティライブラリの特定のバージョンを収集する水銀リポジトリ
• グラフィックリソース/作品のSVNリポジトリ（ただし、他のものに変更される可能性があります）
• 私のアプリケーションの水銀レポ。水銀サブレポ機能を使用して、3番目のparyレポの特定のバージョン、およびいくつかの基本的な拡張を使用します。

「基本」ではない拡張機能（アプリケーションリポジトリのサブリポジトリとして暗黙的に含まれる）で作業する必要がある場合、拡張フォルダー内のリポジトリを複製し、CMakeがアプリケーション全体のプロジェクトとソリューションを生成できるようにします。

そうすれば、次のことができます。

• クローンのサードパーティを変更し、アプリで動作することを確認し、サードパーティリポジトリにプッシュしてから、アプリケーションリポジトリのサブレポバージョンを新しいサードパーティリポジトリバージョンに更新します。
• 拡張機能を個別に、すべて一緒に、または特定の機能を選択する
• プロジェクトをリンクする必要を心配する必要はありません。これは、プロジェクトサブリポジトリをアプリケーションリポジトリ全体でスキャンするだけで、Cmakeによって実行されます。

この組織での経験はまだあまりありませんが、それは非常に便利だと思います。

ソフトウェアがセキュリティ上重要である場合、言い訳はせず、できるだけ早く更新する必要があります。プログラム全体を脆弱にするために、グラフィックスライブラリに小さなバグを追加する必要はありません。

それ以外の場合、ライブラリが成熟しているときは、「壊れていない場合は修正しないでください」です。私のために。遅かれ早かれ、後のバージョンの機能が必要になる可能性があり、更新する以外に選択肢はありませんが、それまで努力を正当化するのは困難です。一方、GrailsやExtJSのような比較的新しいライブラリまたはフレームワークを使用する場合、これらの製品はまだ完全に成熟していないと感じられるため、最新バージョンを使用します。これらのバグの1つに遭遇することから、後のバージョンが修正されました。

NuGetを使用して、サードパーティのライブラリを最新の状態に保ちます。

友人、同僚、またはブログから、サードパーティのDLLの1つが古いことを通知された場合、NuGetを使用すると簡単に更新できます。