Railsを6.1系から7.0系へアップグレードした時に調査したこと
先日、Rails6.1系で動いていたシステムをRails7.0系にアップグレードしました。
そのシステムは
Rails製APIアプリケーション
コード量・利用者ともに小規模
テストコードが充実している
と比較的アップグレードしやすかったこともあり、無事に完了しました。
この記事ではアップグレードの際に調べたことをまとめておきます。
なお、作業はピクシブ株式会社さんの永久保存版Railsアップデートガイドを参考にしながら進めました。ありがとうございました。
リリースノートやRailsガイドのアップグレードガイドを読む
Rails6.1から7.0へアップグレードを計画した段階で、Railsの公式BlogRails7.0系のリリースノートを読みました。
また、Railsガイドのアップグレードガイドの Rails 6.1からRails 7.0へのアップグレードました。
資料を読み終えたところで、対象のシステムは問題なさそうと判断し、準備を進めることにしました。
各gemがRails7.0対応しているか確認する
Rails7.0がリリースされた直後は、使っているgemがRails7.0対応していないものがありました。
そこで、定期的に各gemのリポジトリを見に行き、Rails7.0対応に関するissueやPull Requestを確認しました。
その後、使用しているすべてのgemがRails7.0対応がなされているのが確認できたため、具体的な作業に入りました。
各gemをバージョンアップする
今回は小規模だったこともあり、
bundle outdatedでバージョンアップできるgemを確認Rails以外を
bundle update --conservative <gem名>でバージョンアップ--conservativeオプションにより、指定したgemと指定したgemが直接依存しているgemのみバージョンアップするようになります (Bundlerの公式ドキュメント)
Railsを
bundle update --conservative railsでバージョンアップ
の順で作業をしました。
また、各gemをバージョンアップするごとに、テストを流してパスすることを確認した上でGitブランチにコミットしました。
各種設定ファイルを更新する
次に、6.1系と7.0系間のRailsDiffを見て各種設定ファイルの差分を確認しました。
まず、削除された設定について見てみましたが、主に
Rails7から、Springがデフォルトに含まれなくなったため、Springに関する設定だった
Rails7で
config/initializers/以下が整理されたが、対象システムでは使っていない設定だった
ため、システムから削除しても問題なさそうでした。
次に、設定ファイルの変更で気になった点(後述)については調査を行いました。その結果、変更による影響がなさそうだったため、Rails7.0系での変更を各種設定ファイルに取り入れました。
なお、調査をする際はTechRachoさんの記事が参考になりました。ありがとうございました。
ここでは、今回気になった点とその対応について以下にまとめます。
app/models/application_record.rb
RailsDiffでの差分を引用します。
TechRachoさんの記事を読むと primary_abstract_class の方が良さそうでしたので、差し替えました。
config/environments/development.rb
RailsDiffでの差分のうち、気になった点は以下でした。
TechRachoさんの記事を読むと、server timing ミドルウェアは便利そうでしたので追加することにしました。
一方、
config.assets.debugは使っていないシステムだったconfig.file_watcherはDockerを使っていると影響ありそうな情報が散見されるものの、今回の環境では不要そうだった
ため、これらは設定ファイルから削除することにしました。
config/environments/production.rb
RailsDiffの差分のうち、気になった点は以下でした。
config.active_support.report_deprecations = false については、TechRachoさんの記事 によると一括でdeprecation warningを消せるオプションでした。 ただ、できる限りdeprecation warningは表示したいため、 true にしておきました。
他の項目については、対象のシステムで無効にしていた設定だったため、対応は不要でした。
config/environments/test.rb
RailsDiffの差分のうち、気になった点は以下でした。
この変更を提供したところ、Github Actionsのデフォルトの環境変数 では CI = true が設定されていたことから config.eager_loadが true になってしまい、CI/CDまわりで不具合が出ました。
そのため、 config.eager_load は従来のまま false と明示的に設定しました。
デフォルト値の影響調査
RailsDiffで差分が出たデフォルト値に、 config/application.rb の中のconfig.load_defaults があり、値が 7.0 に変わっていました (該当箇所)。
そこで、Railsのデフォルト値の変更を調べることにしました。
まず、7.0 とした場合の影響については Railsガイドの load_defaults の結果 を参照しながら調査しました。
調査する中で、 rails7へのバージョンアップを安全に行うために使用するnew_framework_defaults_7_0.rbの各項目をさらっと解説 - Qiita に変更内容がまとまっていたため、参考にいたしました。ありがとうございます。
上記の記事にある項目を確認しましたが、今回のシステムに対して影響するものはありませんでした。
次に、さきほどのQiitaの記事で触れられていなかったものについて調査しました。それらを以下にまとめます。
config.active_support.disable_to_s_conversion: true
Railsガイドには
ある種のRubyコアクラスに含まれる#to_sメソッドの上書きを無効にします。この設定は、アプリケーションでRuby 3.1の最適化をいち早く利用したい場合に使えます。
とあります。
今回は小規模なシステムだったこともあり影響がなかったため、デフォルト値の変更を受け入れました。
action_dispatch.return_only_request_media_type_on_content_type: false
edgeのRailsガイド に詳細な記載がありました。
TechRachoさんの記事 を読み、今回のシステムには影響しなかったため、デフォルト値の変更を受け入れました。
active_storage.multiple_file_field_include_hidden: true
edgeのRailsガイドに詳細がありました。
In Rails 7.1 and beyond, Active Storage has_many_attached relationships will default to replacing the current collection instead of appending to it.
とのことですが、今回のシステムには影響しなかったため、デフォルト値の変更を受け入れました。
おわりに
Rails7.0系にアップグレード後も開発・運用を継続していますが、今のところ大きな問題は発生していません。
今後もRailsのバージョンアップを継続して行うとともに、作業で気になったこと等はTechBookに記載していこうと思います。
本サイトの更新情報は、Twitterの株式会社プレセナ・ストラテジック・パートナーズエンジニア公式で発信しています。ご確認ください。
最終更新
役に立ちましたか？