エンジニア1年生が行うGemアップデート手順

自己紹介

エンジニア1年生🐣(25)
大阪の自社開発企業で働いています

はじめに

定期的なライブラリアップデートって大切ですよね！アップデートすれば新機能も増えて便利になるし、ライブラリを見ることはつまり自分たちのプロダクト外のソースコードを見る機会とも言えるので、積極的に行っていきたいものです。

関係ない話ですが、他の方の力を分けてもらってプロダクトに知見を分けてもらうオープンソースの価値観は素晴らしいと思っています。

しかし、日々の業務忙しくて手つけてらんねえ〜〜〜ってなるのもまた事実なわけですが、私の会社ではUPDATE DAYと称して月一アップデートしかしない日を設けています。
UPDATE DAYを設ける以前はだいぶアップデートを後回しにしていたみたいで、10ヶ月前までRailsのバージョンも4.2でしたが、現在では6.1までバージョンを上げることができました。

まあそんなこんなで割と急ピッチでRails周りのアップデートをしていたので、だいぶGemアップデートの手順が定まってきたので忘れないように記事にしたいと思います。

こんなやり方あるぜ〜〜みたいなのも教えてください！🤪

いってみよう！

手順1. アップデート対象になるGemを一覧で表示

bundle outdatedを行うことで、最新バージョンに追いついていないGemを一覧で表示することができます。

手順2. 対象のGemを調査

まずはRubyGemsからgemを検索します。
見る箇所としては、

• RUNTIME依存とDEVELOPMENT依存性
  • 依存Gemのバージョンが足りない場合は上げることはできません。依存Gemを先にあげられるならあげて、ムリそうだったら諦めます。
• 変更履歴
  • この項目はあるGemとないGemが存在しますが、ない場合はGithubに移動してCHANGELOG.mdを見れば同じところに遷移できます。
  • 現状のバージョンとの差分をひとしきり確認していくのですが、特に注意深く見るのは機能追加と非推奨、そして機能削除です。私はBugfixesやRefactorは目を通すくらいで済ませています。時間が許せばしっかり確認しますが。
    • 機能削除
      • removeなどでカテゴライズされていることが多いです。これは問答無用で修正しなければいけない箇所で、修正が困難の場合は、どこかにコメントアウトなどで残しておいた方がいいでしょう。
    • 非推奨
      • deprecatedってやつですね。ここは今後削除される可能性がめちゃくちゃ高いので、今のうちに置き換えられそうならおきかえます。修正が困難の場合にリリースするかは時と場合によりますが、機能削除と同様にコメントかなにかで残しておいた方が良いと思います。
    • 機能追加
      • featuresなど。今後使えそうな機能があればチームに共有してチームの知識として蓄えます。

手順3. 実際にアップデートをする

bundle update Gem名 --conservativeでアップデートします！

--conservativeをつけない場合、依存関係にあるGemもアップデートされてしまうので、時と場合で使い分ける必要があります。私は基本的に--conservativeつけています。

手順4. 自動テスト実行!

自動テストで既存コードが正常に動くことを保証します。

またテストコードで賄えないGemの影響範囲っぽい箇所は実際にシステムを目で見ながら確認もしていきます。

手順5. Gem単位でコミットする

これ結構大事だと思っているんですが、調査してテストを通ってももちろんリリース後にバグ出るみたいことはありえるのでそのリスクに備えなければいけません。

バグが発生した時に、対象のGemだけをrevertして取り消せるようGem単位(もしくは取り消すことができる最小単位)でコミットするように意識しています。

ただこの方法が最善とも思っていなくて、より安全により影響範囲の少ないような方法を模索中です。

手順2~手順5をループ

Gemを調査からコミットまでを対象のGem全てで行います。
すべてを最新にするのは無理だと思うので、そこはぐっとこらえましょう(実際アップデート作業していると多少強引にあげたくなるときもある。。笑)

終わりに

私自身こんなやり方、意識で毎月のUPDATE DAYに望んでいます！
もっといいやり方あれば是非教えていただけると嬉しいです！😎