依存関係はいつ更新する必要がありますか？

2つの異なるコードベース（AndroidとNode.js Webアプリ）を使用した2つの主要な依存関係関連の危機がありました。AndroidリポジトリはFlurryからFirebaseに移行する必要がありました。これには、Google Play Servicesライブラリの4つのメジャーバージョンの更新が必要でした。同様のことが、HerokuがホストするNodeアプリでも発生しました。このアプリでは、実稼働スタック（cedar）が廃止され、cedar-14にアップグレードする必要がありました。PostgreSQLデータベースも9.2から9.6に更新する必要がありました。

これらのアプリの各依存関係はほぼ2年間古く、一部が廃止されて「日没」期間に達したとき、それらを更新または置換することは大きな頭痛の種でした。過去1〜2か月で30時間以上かけて、すべての競合と壊れたコードをゆっくりと解決してきました。

明らかに物事を2年間放置するのは長すぎます。特に、Herokuのようなプラットフォームプロバイダーを使用している場合、テクノロジーは急速に動きます。本格的なテストスイートと、Travis CIのようなCIプロセスがあり、更新から多くの当て推量を取り除くと仮定しましょう。たとえば、アップグレード後に関数が削除され、それを使用している場合、テストは失敗します。

依存関係を更新する頻度、または依存関係を更新するタイミング 強制されたため更新しましたが、何らかの先制的なアプローチの方が良いようです。マイナーバージョンがリリースされたら更新する必要がありますか？メジャーバージョン？更新が利用可能な場合、毎月ですか？どうしても犠牲になったような状況を避けたい。

PS-私の個人的なRailsプロジェクトの1 つでは、Gemnasiumと呼ばれるサービスを使用します。これは、セキュリティの脆弱性などを通知できるように、依存関係を追跡します。これは素晴らしいサービスですが、私が言及したプロジェクトの依存関係を手動で確認する必要があります。

通常、次の場合に依存関係をアップグレードする必要があります。

1. 必須です
2. そうすることには利点があります
3. そうしないことは不利です

（これらは相互に排他的ではありません。）

動機1（「必要なとき」）が最も緊急のドライバーです。依存するコンポーネントまたはプラットフォーム（Herokuなど）がそれを要求しているため、列に並ばなければなりません。多くの場合、必要なアップグレードは他の選択肢からカスケードされます。PostgreSQLバージョンなどにアップグレードすることにしました。ここで、ドライバー、ORMバージョンなどを更新する必要があります。

あなたまたはあなたのチームがそうすることの利点を認識しているため、アップグレードはより柔軟で、よりオプションです。より多くの判断の呼び出し：「新しい機能、能力、パフォーマンス、...それをもたらす労力と転位に値するでしょうか？」Olden Timesでは、オプションのアップグレードに対して強いバイアスがありました。それらは手動で難しく、サンドボックスで試してみる良い方法がありませんでしたまたは仮想環境、または更新がうまくいかなかった場合に更新をロールバックし、更新が「アップルカートを混乱させた」ことを確認するための高速自動テストがありませんでした。現在、バイアスははるかに高速で、より積極的な更新サイクルに向かっています。アジャイルメソッドは物事を試すのが大好きです。自動インストーラー、依存関係マネージャー、およびリポジトリにより、インストールプロセスが高速になり、多くの場合ほとんど見えなくなります。仮想環境とユビキタスバージョン管理により、ブランチ、フォーク、およびロールバックが簡単になります。自動化されたテストにより、更新を試してから、簡単かつ十分な評価を行うことができました。「動作しましたか？バイアスは、「壊れていない場合は修正しないでください」から「早めに更新し、頻繁に更新する」に大まかにシフトしました

モチベーション3は最もソフトです。ユーザーストーリーは「配管」に関心がなく、「現在のインフラストラクチャの背後にあるリリースをN個以下に抑える」ことは決して言及しません。バージョンドリフトの不利な点（おおむね、曲線に遅れをとることに関連する技術的負債）は静かに侵入し、しばしば破損によって自らを発表します。「申し訳ありませんが、そのAPIはサポートされなくなりました！」アジャイルチーム内であっても、特定のスプリントまたはリリースを完了するために重要であると見なされていない場合、コンポーネントのフレッシュさをインクリメンタリズムおよび「常に把握」するように動機付けることは困難です。誰もが更新を提唱していない場合、彼らは手付かずになることができます。そのホイールは、壊れる準備ができるまで、または壊れるまではきしむことはありません。

実用的な観点から、チームはバージョンドリフトの問題にもっと注意を払う必要があります。2年は長すぎます。魔法はありません。「今すぐ支払うか、後で支払う」だけです。バージョンドリフトの問題に段階的に対処するか、数年ごとに大きな衝撃を乗り越えて乗り越えてください。プラットフォームの衝撃のいくつかは非常に大きいため、インクリメンタリズムを好みます。依存している主要なAPIまたはプラットフォームは、1日、1週間、または1か月を本当に台無しにします。私はコンポーネントの鮮度を少なくとも年に1〜2回評価したいです。レビューを明示的にスケジュールするか、Python、PostgreSQL、node.jsなどの主要コンポーネントの比較的メトロノーム的な、通常は年1回の更新サイクルによってレビューを有機的にトリガーできます。コンポーネントの更新によってチームがあまり強くトリガーされない場合、メジャーリリースの鮮度チェック、自然なプロジェクトの高原、またはkごとのリリースでも機能します。より規則的なリズムでのバージョンドリフトの修正に注意を払うものは何でも。

ライブラリは、更新が必要なときに更新する必要があります。つまり、更新が価値をもたらさない場合は、そうすべきではありません。

特定のケースでは、古い技術スタックから新しい技術スタックに移行していましたが、そのために依存関係を更新する必要がありました。その瞬間が、依存関係を更新する正しいタイミングです。

「頭痛の種」にならないように、時間の経過とともに依存関係を更新していた場合、戻り値がないために多くの作業時間（コーディング）を投資する必要がありました。そして、あなたが最後の更新を行うとき（あなたが今しているものですが、4ではなく1つのメジャーバージョンを更新する）、おそらくどこかに頭痛が残っているでしょう（結局、メジャーバージョンは変更を壊すことを意味します）。だから私はあなたが正しい道にいると思う。

ただし、移行が非常に難しく、多くのリファクタリングを行う必要がある場合は、コードベースに問題がある可能性があります。Androidプロジェクトでは、コード構造の観点から全体的なアーキテクチャを持たないことが非常に一般的です。Dagger 2のような優れた依存性注入フレームワーク、およびSOLIDのようなソフトウェアエンジニアリングの原則により、同じ動作/要件を維持しながらコード実装を簡単に変更できます。

また、リファクタリングを行っているので、この種の作業を行う際に非常に役立つため、ユニットテストについて少し読んでください。

パッケージ管理ツール（npm、NuGetなど）を使用しており、包括的な自動テストスイートがある場合、依存関係のアップグレードは簡単な作業であり、単にパッケージをアップグレードし、テストスイートを実行して問題があるかどうかを確認します。次にロールバックがあり、ワークアイテムを上げて問題を調査して修正する場合。

依存関係をアップグレードするコストが低い限り、最新の状態に保つ価値があります。

• アップグレードに問題がある場合は、アップストリームの変更が必要になった場合に備えて、後よりも早く知りたいと思います。
• 依存関係のアップグレードを最後の最後まで残すことは、多くの場合、クランチ時にそれらのアップグレードを実行していることを意味します（たとえば、セキュリティ上の重大なバグへの応答）。依存関係を常に把握するということは、いつその労力を費やすかを管理し、忙しくないときにそれらのアップグレードを実行できることを意味します。
• 新しいバージョンでは、ドキュメントの改善、APIの使いやすさ、バグ修正などの生産性が向上する場合があります（ただし、逆も可能です）。

依存関係のアップグレードの労力が少ない場合（たとえば、アップグレードを手動でテストする必要がある場合、または既知の問題/重大な変更があるため）、他のタスクとの長所と短所を比較検討する必要があります。古い依存関係は一種の低利の技術的負債なので、それに応じて処理する必要があります。

古いバージョンの依存関係がサポートされている場合を除き、依存関係の古いバージョンを意図的に使用しているリリースは実行しないでください。

つまり、V1を使用していて、まだサポートされている場合でも、v1の最新バージョンを使用できます。

古くなっているのは、次の場合のみです。

A：しばらくリリースしていません。

B：v1を使用していたため、サポートされなくなりました

アップデートには理由があるため、リリースされるセキュリティ修正が含まれています。

依存関係の新しいバージョンが公開された場合は、リリースも行う必要があります

問題のライブラリにある程度依存する必要があると思いますが、私自身も同様の依存関係の頭痛の種を抱えています。

常識的には、メジャーバージョンはおそらくアップグレードするのに適切な時期であり、重大な欠陥に対処するか、重要な利点を含むマイナーバージョンはそれよりも優先されると私に言います。

メンテナンスを必要とするすべてのアプリケーションで作業したり、ミッションクリティカルなアプリケーションの展開を解除したりする余裕がない場合もありますが、最終的には噛み付き、1オンスの予防策で1ポンドの治療に打ち勝ちます！

ライブラリは、変更に費やした作業を補うソフトウェアが使用するという利点がある場合に更新する必要があります。

ライブラリのマイナーバージョンのアップグレードでさえ、アプリの不整合を解消または挿入する可能性があります。その観点から、小さな変更はありません。

古いライブラリを使用することに恥はありません。変更が必要なときは苦痛かもしれませんが、それは仕事の一部です。