依存関係はいつ更新する必要がありますか？
2つの異なるコードベース（AndroidとNode.js Webアプリ）で、依存関係に関連する2つの大きな危機がありました。 AndroidリポジトリはFlurryからFirebaseに移行する必要があり、これにはGoogle Play Servicesライブラリfourメジャーバージョンの更新が必要でした。同様のことがHerokuがホストするNodeアプリで、本番スタック（cedar）は非推奨になり、cedar-14にアップグレードする必要がありました。PostgreSQLデータベースも9.2から9.6に更新する必要がありました。
これらのアプリの依存関係のそれぞれは、ほぼ2年間陳腐化しており、一部が廃止され、「日没」期間に達したとき、それはmajorでしたそれらを更新するか、それらを交換する頭痛。過去1か月間で30時間以上費やして、すべての競合と壊れたコードをゆっくりと解決しました。
明らかに、2年間放置するのは長すぎます。特にHerokuのようなプラットフォームプロバイダーを使用している場合、テクノロジーは急速に変化します。本格的なテストスイートと、Travis CIのようなCIプロセスがあると仮定しましょう。これにより、多くの推測を更新から取り除くことができます。例えば。アップグレード後に関数が削除され、それを使用していた場合、テストは失敗します。
依存関係を更新する頻度、またはいつ依存関係を更新する必要がありますか？強制されたため、更新しましたへ、しかし、ある種の先制アプローチの方が良いようです。マイナーバージョンがリリースされたときに更新する必要がありますか？メジャーバージョン？更新が利用可能な場合、毎月？今体験したようなことは絶対に避けたいです。
PS-私の個人のRailsプロジェクトの1つについて、私は Gemnasium と呼ばれるサービスを使用します。これにより、依存関係を追跡して、セキュリティの脆弱性などを通知できるようにします。サービスですが、私が言及したプロジェクトの依存関係を手動で確認する必要があります。
通常、次の場合に依存関係をアップグレードする必要があります。
- 必須です
- そうすることには利点があります
- そうしないと不利です
（これらは相互に排他的ではありません。）
動機1（「必要なとき」）が最も緊急のドライバーです。依存している一部のコンポーネントまたはプラットフォーム（Herokuなど）はそれを要求し、それに合わせなければなりません。多くの場合、必要なアップグレードは他の選択肢からカスケードされます。 PostgreSQLバージョンにアップグレードすることに決めました。次に、ドライバー、ORMバージョンなどを更新する必要があります。
あなたまたはあなたのチームがそうすることの利点を認めているので、アップグレードはより柔らかく、よりオプションです。より多くの判断の呼びかけ：「新しい機能、能力、パフォーマンスなどは、努力の価値があり、それをもたらす混乱はそれを引き起こすでしょうか？」 Olden Timesでは、オプションのアップグレードに対する強い偏見がありました。それらは手動で困難であり、 sandbox または仮想環境で試すことも、うまくいかなかった場合に更新をロールバックすることも、高速でなかったこともありませんでした。更新が「=Appleカートを混乱させる」ことを確認しなかったことを確認する自動テスト。今日のバイアスは、はるかに高速で、より積極的な更新サイクルに向かっています。アジャイルメソッドは、物事を試みることを好みます;自動インストーラ、依存関係マネージャとレポジトリはインストールプロセスを高速にし、ほとんど目に見えないものにします。仮想環境とユビキタスバージョンコントロールにより、ブランチ、フォーク、ロールバックが簡単になります。自動テストにより、アップデートを簡単に、そして実質的に評価できます。 ？ "バイアスは、「それが壊れていない場合は修正しないでください」から「早期更新、頻繁更新」モードの 継続的統合 および 継続的配送 。
動機3は最もソフトです。ユーザーストーリーは、「配管」に関係することはなく、「現在のインフラストラクチャの背後にあるNリリース以下のインフラストラクチャを維持する」ことについては言及していません。バージョンドリフトのデメリット（大まかに言えば、曲線に遅れをとることに伴う技術的負債）は静かに侵入し、その後、破損によって自分自身を発表することがよくあります。 「申し訳ありませんが、そのAPIはサポートされていません！」アジャイルチーム内であっても、特定のスプリントやリリースの完了にとって極めて重要であると見なされていない場合、インクリメンタリズムを動機付けし、コンポーネントの鮮度を「維持する」ことは難しい場合があります。誰も更新を主張しない場合、彼らは無制限に行くことができます。壊れる準備ができるまで、または壊れるまで、そのホイールはきしみません。
実用的な観点から、チームはバージョンドリフトの問題にもっと注意を払う必要があります。 2年は長すぎます。魔法はありません。それは、「今すぐ支払うか、後で支払うか」の問題です。バージョンドリフトの問題に段階的に対処するか、数年ごとに大きな衝撃を乗り越えて対処します。一部のプラットフォームの衝撃は非常に大きいので、私は漸進主義を好みます。動作しなくなった依存している主要なAPIまたはプラットフォームは、実際に1日、1週間、または1か月を台無しにする可能性があります。私は、コンポーネントの鮮度を少なくとも年に1〜2回評価するのが好きです。レビューを明示的にスケジュールすることも、比較的メトロノーム的な、通常はPython、PostgreSQL、node.jsなどの主要コンポーネントの毎年の更新サイクルによって有機的にトリガーさせることもできます。コンポーネントの更新によってチームが強くトリガーされない場合は、メジャーリリース、自然なプロジェクトプラトー、またはkリリースごとの鮮度チェックでも機能します。より規則的なリズムでバージョンドリフトを修正することに注意を向けるものは何でも。
ライブラリは、更新が必要なときに更新する必要があります。つまり、更新しても価値がない場合は、そうするべきではありません。
あなたの特定のケースでは、古い技術スタックから新しい技術スタックに移行していて、そのために依存関係を更新する必要がありました。その瞬間が、依存関係を更新する正しいタイミングです。
依存関係を時間をかけて更新していた場合、「今は頭痛の種」を解消するために、戻り値がないために多くの作業時間（コーディング）を費やす必要がありました。最後の更新（現在実行しているものですが、4ではなく1つのメジャーバージョンを更新します）を実行した場合、おそらくどこかで頭痛がするでしょう（結局、メジャーバージョンは変更を壊すことを意味します）。だからあなたは正しい道を進んでいると思います。
ただし、移行が難しく、多くのリファクタリングを行う必要がある場合、問題はコードベースにある可能性があります。 Androidプロジェクトがコード構造の観点から全体的なアーキテクチャを持たないことはかなり一般的です。Dagger 2 のような優れた依存性注入フレームワーク=、および [〜＃〜] solid [〜＃〜] のようないくつかのソフトウェアエンジニアリングの原則により、コードの実装を変更せずに、変更を容易にすることができます動作/要件。
また、リファクタリングを行っているので、ユニットテストについて少し読んでください。これは、この種の作業を行うときに非常に役立ちます。
パッケージ管理ツール（npm、NuGetなど）を使用していて、包括的な自動テストスイートがある場合、依存関係のアップグレードは簡単な作業であり、パッケージをアップグレードしてテストスイートを実行し、問題がないか確認します。その後、ロールバックしてワークアイテムを発生させ、問題を調査して修正します。
依存関係のアップグレードのコストが低い限り、最新に保つ価値は十分にあります。
- アップグレードに問題がある場合は、上流の変更が必要な場合に備えて、後でではなく早く知りたいと考えています。
- 依存関係のアップグレードを最後まで残しておくことは、多くの場合、それらのアップグレードを（たとえば、セキュリティ上の重大なバグへの対応など）危機的な時間に実行していることを意味します。依存関係を常に把握しているということは、その作業に費やす時間を管理でき、忙しくないときにアップグレードを実行できることを意味します。
- 新しいバージョンでは、生産性が向上する場合があります。より良いドキュメント、より使いやすいAPI、バグ修正（逆も可能です）。
依存関係のアップグレードが簡単ではない場合（たとえば、アップグレードを手動でテストする必要があるため、または既知の問題/重大な変更があるため）、他の長所と短所を比較検討する必要があります。古い依存関係は一種の低金利の技術的負債なので、それに応じて処理する必要があります。
古いバージョンの依存関係を意図的に使用しているリリースは、それらのバージョンがサポートされている代替手段でない限り、実行しないでください。
つまり、V1を使用していてもサポートされている場合は、最新バージョンのv1を使用できます。
あなたが時代遅れであるべき唯一の時間は次の場合です：
A：しばらくリリースを行っていません。
B：v1を長期間使用しているため、サポートされなくなりました
更新は理由のためにリリースされ、それらはあなたが船上で取るべきセキュリティ修正を含んでいます。
依存関係の新しいバージョンが出てきた場合は、リリースも行う必要があります
問題のライブラリにある程度依存していると思いますが、私自身も同様の依存性の頭痛の種を抱えていました。
常識的に言えば、メジャーバージョンはおそらくアップグレードに適した時期であり、マイナーバージョンは重大な欠陥に対処するか、大きなメリットを含むため、それよりも優先されます。
時々、メンテナンスを必要とするすべてのアプリケーションに取り組む余裕がない、またはミッションクリティカルなアプリケーションをアンデプロイすることさえできない場合がありますが、それらは最終的にあなたに噛み付き、1オンスの防止策はしばしば治療法を打ち負かします！
ライブラリは、変更に費やされた作業を補うためにソフトウェアが使用する利点を提供するときに更新する必要があります。
ライブラリバージョンのマイナーアップグレードでも、アプリの不整合が解消または挿入される可能性があります。その観点からは、小さな変更はありません。
古いライブラリを使用することに恥はありません。変更が必要なときは苦痛かもしれませんが、それは仕事の一部です。