この記事は Ubiregi Advent Calendar 2020 24日目のエントリです。
gem の更新は放っておくといつの間にか差分が大量になっていて確認作業が大変になったり、
無用心に breaking change のある更新を行なってしまうとアプリケーションが壊れてしまったりしまいますね。
そうならないように日頃 gem updateをしていることだと思います。
gem updateの仕方自体は手動で bundle update したり Dependabot を導入したりがあると思いますが、今回はそれらによって生まれた更新内容を見ていく手順を書いていこうと思います。
まずはCHENGELOGをみます。
CHENGELOGから読み取る内容
CHANGELOGを見て影響が小さいとわかる場合
例ですが、変更が小さくこまめに更新があるgemといえば aws-sdk-~~~ が代表的かなと思っています。
awsのgemを知らない方でも 以下のCHANGELOGを見ると１〜２日に１回は更新があることがわかります。
ws-sdk-s3/CHANGELOG.md
aws-sdk-ec2/CHANGELOG.md
頻度は多いですが、大抵の更新内容は影響ないものです。
使っていない機能のサポート追加や ちょっとした issue の修正対応だったりが多いです。
（テストがしっかり書いてあることが前提ですが）こういった場合はテストが通っているのが確認できたらマージして問題ない更新だと判断できます。
CHENGELOGに Breaking Changes と書いてある場合
Breaking Changes とか BREAKING など書いてあるのは破壊的な変更ですので、無用心にgemのバージョンを上げてしまうとアプリが壊れる可能性があります。
Breaking Changes の内容をよく確認します。
例、サポートの終了
5.0以下のバージョンのrailsのサポートを終わる とかなら使っているバージョンと比較します。
例、引数やメソッドの名前変更、廃止など
例 faker/CHANGELOG.md at master · faker-ruby/faker
変更のあったメソッドがアプリで使われていないか検索し、あれば修正する必要があります。
場合によってはCIが落ちていてそこから気づくこともあります。
直し方まで記載されている親切なCHENGELOGもありますので、そういう場合は直し方に従って修正します。
CHENGELOGに直し方が書いていなかった場合、対応するPullRequestのissueやコミットやConversationから読み取って修正します。
CHENGELOG以外から読み取る内容
CHANGELOGの内容から判断できなかった場合
CHENGELOGをみても更新内容がいまいちわからなかった時はPRやissueを見に行きます。
CHENGELOGには大抵の場合元になったPRのリンクがありますので、そのPRのdescriptionや 元になった issue の内容を確認し、変更の意図を把握します。
この時点で自分のアプリケーションに関係がありそうな変更かどうかなんとなくわかりますが、
無関係なら影響なしと判断したり、気になったならコミットや差分を見て判断します。
CIが落ちている
まとめて bundle update している場合はどのgem updateが原因でそうなったかの特定からですが、
各gem ごとにbundle update [gem] している場合はそのgemが原因とわかりますので
上の手順のような、CHENGELOGを見るなどして原因と直し方を把握し、修正します。
記事を探してみる
例,
RuboCop 1.0 がリリースされた - koicの日記
https://koic.hatenablog.com/entry/rubocop-1-0-has-been-released
利用者の多いgemのメジャーアップデートや何か大きな変更があったときは
記事を書いてくださる方もおりますので探してみると見つかったりします。
CHENGELOGがない場合
gemによってはたまにあります。そういう時は
Comparing v2.7.0...v2.9.1 · rubocop-hq/rubocop-rails
https://github.com/rubocop-hq/rubocop-rails/compare/v2.7.0...v2.9.1
のように
https://github.com/[ユーザーネーム]/[gemの名前]/compare/[バージョンアップ前]...[バージョンアップ後]
でコミットの履歴を確認しています。
gemによっては CHENGELOG ではなく news みたいなファイル名なのもあった記憶があります。
たいてい CHENGELOG ですが、別の名前のも見かけることありますので、探してみると違うファイル名で見つかったりすることもあります。
ですがCHENGELOGがない場合はバージョン間のコミット一覧からPRを見ていくしかないかなと思っています。
よく知らないgemのバージョンが上がっていた場合
gemのREADMEや使い方の記事を検索してみて
・どのようなgemか
・どのように使うgemか
を知って自分のアプリでどのように使われているかをコード検索して調べます。
どんなgemか、というのとどう使っているかを把握したら改めてCHENGELOGなどを見て影響があるかないかを確認します。
調べている最中に、自分のアプリではもはや使っていないgemとわかることがあります。
そういう時はGemfileから削除するPRを別途作ります。
動作確認
アプリケーションによってどんなgemが重要かは様々かと思いますが、機能に大きな影響があるgemの場合は 上の手順でCHENGELOG等を見て大丈夫そうだと思った場合でもローカル環境やテスト環境で実際に動作確認することがあります。
テストが不足していて思わずCIが通っていたり、変更内容の確認を間違えていた場合に気づくことができます。
まとめ
上記の内容の確認をgemへの理解度やgemの重要度や影響度に応じてこまめにみたり、大雑把にみたりしてgemアップデートの内容を確認します。
gemのアップデートを確認した際には
CEHNGELOGを見る限り、（〜〜〜）だけのような変更です。
のように
・どのように差分の内容を把握したか
・どんな内容の差分だったか
・（場合によっては）実際に動作確認してみた結果
をコメントしPRを承認します。
無言で承認するより、「確認方法や差分についてこう理解したのでOKだと思った」
というコメントがあったほうが他の人が見た時も納得、安心するのでコメントするようにします。
参考
仕事で行うRuby/Railsのgem update手順 - Qiita
GitHubで特定のリビジョン間の差分を確認する方法 - Qiita
最後に
今思うと見たり聞いたりした知識で我流でgemアップデートの確認していました。
他の人はどうやって確認しているのかあまり聞く機会がないです。
こうしたほうがいいとかいいやり方がございましたらコメントしていただけたらと思います。