gem update時の確認でやっていること　見ているところ

この記事は [Ubiregi Advent Calendar 2020](https://qiita.com/advent-calendar/2020/ubiregi) 24日目のエントリです。


gem の更新は放っておくといつの間にか差分が大量になっていて確認作業が大変になったり、
無用心に breaking change のある更新を行なってしまうとアプリケーションが壊れてしまったりしまいますね。
そうならないように日頃 gem updateをしていることだと思います。

gem updateの仕方自体は手動で `bundle update` したり [Dependabot](https://dependabot.com/) を導入したりがあると思いますが、今回はそれらによって生まれた更新内容を見ていく手順を書いていこうと思います。

まずはCHENGELOGをみます。

#  CHENGELOGから読み取る内容

## CHANGELOGを見て影響が小さいとわかる場合

例ですが、変更が小さくこまめに更新があるgemといえば `aws-sdk-~~~` が代表的かなと思っています。
awsのgemを知らない方でも 以下のCHANGELOGを見ると１〜２日に１回は更新があることがわかります。

[ws-sdk-s3/CHANGELOG.md](https://github.com/aws/aws-sdk-ruby/blob/dea37916f1629305a149308a2dd5ef386c55d2df/gems/aws-sdk-s3/CHANGELOG.md)
[aws-sdk-ec2/CHANGELOG.md](https://github.com/aws/aws-sdk-ruby/blob/dea37916f1629305a149308a2dd5ef386c55d2df/gems/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](https://github.com/faker-ruby/faker/blob/master/CHANGELOG.md#important-note)

変更のあったメソッドがアプリで使われていないか検索し、あれば修正する必要があります。
場合によっては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](https://qiita.com/TeruhisaFukumoto/items/a4bfafe51b455b6c5ad2)

[GitHubで特定のリビジョン間の差分を確認する方法 - Qiita]
(https://qiita.com/bigplants/items/0a31b5cc2290d13edb51)



# 最後に

今思うと見たり聞いたりした知識で我流でgemアップデートの確認していました。
他の人はどうやって確認しているのかあまり聞く機会がないです。
こうしたほうがいいとかいいやり方がございましたらコメントしていただけたらと思います。