Railsを6.1系から7.0系へアップグレードした時に調査したこと
最終更新
役に立ちましたか?
最終更新
役に立ちましたか?
先日、Rails6.1系で動いていたシステムをRails7.0系にアップグレードしました。
そのシステムは
Rails製APIアプリケーション
コード量・利用者ともに小規模
テストコードが充実している
と比較的アップグレードしやすかったこともあり、無事に完了しました。
この記事ではアップグレードの際に調べたことをまとめておきます。
なお、作業はピクシブ株式会社さんのを参考にしながら進めました。ありがとうございました。
Rails6.1から7.0へアップグレードを計画した段階で、Rails7.0系のリリースノートを読みました。
また、Railsガイドのアップグレードガイドの ました。
資料を読み終えたところで、対象のシステムは問題なさそうと判断し、準備を進めることにしました。
Rails7.0がリリースされた直後は、使っているgemがRails7.0対応していないものがありました。
そこで、定期的に各gemのリポジトリを見に行き、Rails7.0対応に関するissueやPull Requestを確認しました。
その後、使用しているすべてのgemがRails7.0対応がなされているのが確認できたため、具体的な作業に入りました。
今回は小規模だったこともあり、
bundle outdated
でバージョンアップできるgemを確認
Rails以外を bundle update --conservative <gem名>
でバージョンアップ
Railsを bundle update --conservative rails
でバージョンアップ
の順で作業をしました。
また、各gemをバージョンアップするごとに、テストを流してパスすることを確認した上でGitブランチにコミットしました。
まず、削除された設定について見てみましたが、主に
Rails7で config/initializers/
以下が整理されたが、対象システムでは使っていない設定だった
ため、システムから削除しても問題なさそうでした。
次に、設定ファイルの変更で気になった点(後述)については調査を行いました。その結果、変更による影響がなさそうだったため、Rails7.0系での変更を各種設定ファイルに取り入れました。
ここでは、今回気になった点とその対応について以下にまとめます。
一方、
config.assets.debug
は使っていないシステムだった
config.file_watcher
はDockerを使っていると影響ありそうな情報が散見されるものの、今回の環境では不要そうだった
ため、これらは設定ファイルから削除することにしました。
他の項目については、対象のシステムで無効にしていた設定だったため、対応は不要でした。
そのため、 config.eager_load
は従来のまま false
と明示的に設定しました。
そこで、Railsのデフォルト値の変更を調べることにしました。
上記の記事にある項目を確認しましたが、今回のシステムに対して影響するものはありませんでした。
次に、さきほどのQiitaの記事で触れられていなかったものについて調査しました。それらを以下にまとめます。
ある種のRubyコアクラスに含まれる#to_sメソッドの上書きを無効にします。この設定は、アプリケーションでRuby 3.1の最適化をいち早く利用したい場合に使えます。
とあります。
今回は小規模なシステムだったこともあり影響がなかったため、デフォルト値の変更を受け入れました。
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に記載していこうと思います。
--conservative
オプションにより、指定したgemと指定したgemが直接依存しているgemのみバージョンアップするようになります ()
次に、を見て各種設定ファイルの差分を確認しました。
ため、Springに関する設定だった
なお、調査をする際はさんの記事が参考になりました。ありがとうございました。
を引用します。
を読むと primary_abstract_class
の方が良さそうでしたので、差し替えました。
のうち、気になった点は以下でした。
を読むと、server timing ミドルウェアは便利そうでしたので追加することにしました。
のうち、気になった点は以下でした。
config.active_support.report_deprecations = false
については、 によると一括でdeprecation warningを消せるオプションでした。 ただ、できる限りdeprecation warningは表示したいため、 true
にしておきました。
のうち、気になった点は以下でした。
この変更を提供したところ、 では CI = true
が設定されていたことから config.eager_load
が true
になってしまい、CI/CDまわりで不具合が出ました。
RailsDiffで差分が出たデフォルト値に、 config/application.rb
の中のconfig.load_defaults
があり、値が 7.0
に変わっていました ()。
まず、7.0
とした場合の影響については を参照しながら調査しました。
調査する中で、 に変更内容がまとまっていたため、参考にいたしました。ありがとうございます。
には
に詳細な記載がありました。
を読み、今回のシステムには影響しなかったため、デフォルト値の変更を受け入れました。
に詳細がありました。
本サイトの更新情報は、Twitterので発信しています。ご確認ください。