Railsアプリケーション内のすべての宝石を安全に更新する方法

Question

Railsアプリケーションには何百もの依存関係があり、未確認のまま残しておくことが一般的です。 bundle outdatedを実行して古くなった100以上の宝石のリストを取得した後、私はちょっと調べて、すべてのものを探し、そのCHANGELOGを見つけ、更新が何かを壊していないことを確認します。 update a single gemへの確認された方法は、すべての依存関係を引き出すことなく行われているようにも見えません。

自動テストに合格した後、別のコミットで各gemを更新すると思われるthis projectが見つかりました。これはプロセスを合理化するのに役立ちますが、どの宝石バージョンのアップグレードにDSL変更が含まれているかはわかりません（this oneなど）。時々、私は盲目的にマイナーバージョンまたはパッチバージョンをチェックせずに更新します。著者がSEMVERのようなバージョン管理規則に従うことを期待しています。他の時間には、ドキュメントはありません（ヒストリーファイルまたはCHANGELOGファイルはありません）。

私自身のコードを書くときは、すべての行をコミットする前に必ず確認します。ライブラリの更新にも同じ注意が必要ですか？通常、図書館を最初に含めた場合、多くの勤勉さはありませんでした。しかし、グリーンフィールドプロジェクトでは、他の人々のコードを活用することによって、失うことはほとんどなく、多くの利益を得ることができます。成熟したプロジェクトでは、新しい障害に対する耐性はほとんどありません。

更新プログラムを1つずつ取得し、差分を見て変更を表示し、変更があればCHANGELOGを表示し、テストスイートを実行するためのツールやプロセスはありますか？

Answer 1

私の戦略は、可能なときにはいつでも、いくつかの宝石を時々更新することです。明らかに依存関係ツリーはこれを困難にする可能性がありますが、私は盲目的にbundle updateを実行して数回焼き付けました。特に、100以上の宝石を持つ大規模プロジェクトでは、これは避けてください。小規模なグループの宝石を更新することで、副作用が簡単に分離して対処できるという利点もあります。

また、Gemfile/Gemfile.lockの変更に対して、専用のgitコミットを使用する習慣を作っています。したがって、すべての依存関係の更新では、これら2つのファイルの変更のみを含む1つのコミットがあります。これにより、git bisectでデバッグが簡単になり、必要に応じて変更を元に戻すことが容易になります。また、依存関係解決の必然的な試行錯誤のプロセスに役立ちます。私はこの戦略が移行にもうまくいくことを見出しました（ただし、移行は依存関係IMOよりも厄介です）。

もちろん、Rails、Sidekiq、ActiveAdmin、RSpecなどのような主要な依存関係の更新があります。 al。しかし、それは比較的まれであり、「より薄い」依存関係を維持しているので、この丸薬は飲み込むのが少し楽になります。