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での差分を引用します。

class ApplicationRecord< ActiveRecord::Base
-  self.abstract_class = true
+  primary_abstract_class
end

TechRachoさんの記事を読むと primary_abstract_class の方が良さそうでしたので、差し替えました。

config/environments/development.rb

RailsDiffでの差分のうち、気になった点は以下でした。

+ config.server_timing = true

- config.assets.debug = true

- config.file_watcher = ActiveSupport::EventedFileUpdateChecker

TechRachoさんの記事を読むと、server timing ミドルウェアは便利そうでしたので追加することにしました。

一方、

config.assets.debug は使っていないシステムだった
config.file_watcher はDockerを使っていると影響ありそうな情報が散見されるものの、今回の環境では不要そうだった

ため、これらは設定ファイルから削除することにしました。

config/environments/production.rb

RailsDiffの差分のうち、気になった点は以下でした。

-  # Send deprecation notices to registered listeners.
-  config.active_support.deprecation = :notify
-
-  # Log disallowed deprecations.
-  config.active_support.disallowed_deprecation = :log
-
-  # Tell Active Support which deprecation messages to disallow.
-  config.active_support.disallowed_deprecation_warnings = []
+  # Don't log any deprecations.
+  config.active_support.report_deprecations = false

config.active_support.report_deprecations = false については、TechRachoさんの記事によると一括でdeprecation warningを消せるオプションでした。ただ、できる限りdeprecation warningは表示したいため、 true にしておきました。

他の項目については、対象のシステムで無効にしていた設定だったため、対応は不要でした。

config/environments/test.rb

RailsDiffの差分のうち、気になった点は以下でした。

-  # Do not eager load code on boot. This avoids loading your whole application
-  # just for the purpose of running a single test. If you are using a tool that
-  # preloads Rails for running tests, you may have to set it to true.
-  config.eager_load = false
+  # Eager loading loads your whole application. When running a single test locally,
+  # this probably isn't necessary. It's a good idea to do in a continuous integration
+  # system, or in some way before deploying your code.
+  config.eager_load = ENV["CI"].present?

この変更を提供したところ、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の株式会社プレセナ・ストラテジック・パートナーズエンジニア公式で発信しています。ご確認ください。

前へRailsのアプリケーションサーバーのプロセス数とスレッド数の設定方法次へschema.rbで差分が発生する事例とその復旧について

最終更新 2 年前

役に立ちましたか？

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/ 以下が整理されたが、対象システムでは使っていない設定だった

ため、システムから削除しても問題なさそうでした。

なお、調査をする際はTechRachoさんの記事が参考になりました。ありがとうございました。

ここでは、今回気になった点とその対応について以下にまとめます。

app/models/application_record.rb

RailsDiffでの差分を引用します。

class ApplicationRecord< ActiveRecord::Base
-  self.abstract_class = true
+  primary_abstract_class
end

TechRachoさんの記事を読むと primary_abstract_class の方が良さそうでしたので、差し替えました。

config/environments/development.rb

RailsDiffでの差分のうち、気になった点は以下でした。

+ config.server_timing = true

- config.assets.debug = true

- config.file_watcher = ActiveSupport::EventedFileUpdateChecker

TechRachoさんの記事を読むと、server timing ミドルウェアは便利そうでしたので追加することにしました。

一方、

config.assets.debug は使っていないシステムだった
config.file_watcher はDockerを使っていると影響ありそうな情報が散見されるものの、今回の環境では不要そうだった

ため、これらは設定ファイルから削除することにしました。

config/environments/production.rb

RailsDiffの差分のうち、気になった点は以下でした。

-  # Send deprecation notices to registered listeners.
-  config.active_support.deprecation = :notify
-
-  # Log disallowed deprecations.
-  config.active_support.disallowed_deprecation = :log
-
-  # Tell Active Support which deprecation messages to disallow.
-  config.active_support.disallowed_deprecation_warnings = []
+  # Don't log any deprecations.
+  config.active_support.report_deprecations = false

他の項目については、対象のシステムで無効にしていた設定だったため、対応は不要でした。

config/environments/test.rb

RailsDiffの差分のうち、気になった点は以下でした。

-  # Do not eager load code on boot. This avoids loading your whole application
-  # just for the purpose of running a single test. If you are using a tool that
-  # preloads Rails for running tests, you may have to set it to true.
-  config.eager_load = false
+  # Eager loading loads your whole application. When running a single test locally,
+  # this probably isn't necessary. It's a good idea to do in a continuous integration
+  # system, or in some way before deploying your code.
+  config.eager_load = ENV["CI"].present?

そのため、 config.eager_load は従来のまま false と明示的に設定しました。

デフォルト値の影響調査

RailsDiffで差分が出たデフォルト値に、 config/application.rb の中のconfig.load_defaults があり、値が 7.0 に変わっていました (該当箇所)。

そこで、Railsのデフォルト値の変更を調べることにしました。

まず、7.0 とした場合の影響については Railsガイドの load_defaults の結果を参照しながら調査しました。

上記の記事にある項目を確認しましたが、今回のシステムに対して影響するものはありませんでした。

次に、さきほどの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の株式会社プレセナ・ストラテジック・パートナーズエンジニア公式で発信しています。ご確認ください。

前へRailsのアプリケーションサーバーのプロセス数とスレッド数の設定方法次へschema.rbで差分が発生する事例とその復旧について

最終更新 2 年前

役に立ちましたか？