初めてのRailsバージョンアップ経験の振り返りをしてみる
本記事は株式会社ココナラ Advent Calendar 2024 6日目の記事になります。
こんにちは。
株式会社ココナラ バックエンド開発チームのtoruchanと申します
みなさんはシステムのバージョンアップ対応を経験したことはありますか？
私は今年初めてRailsバージョンアップ対応の経験をしました。
本記事では私が担当したRailsバージョンアップ対応についての振り返りを行っていこうと思います。
バージョンの差分について
バージョンアップ前後のRuby/Railsのバージョンの差分は下記の通りです。
Rubyは2系から3系、Railsは5系から7系への変更を行いました。
| バージョンアップ前 | バージョンアップ後 | |
|---|---|---|
| Ruby | 2.5.5 | 3.2.5 |
| Rails | 5.2.3 | 7.1.2 |
個人的な学びがあったポイント
本記事では個人的に学びのあったポイントとして、主に以下の内容について触れていきます。
- そもそもバージョンアップってどう進めるの？
- テストコードの重要性の再認識
- テストコードだけではカバーできなかった問題
- 外部サービスとの連携部分
- テストケースが一部存在しない部分
- どのように検知&修正を進めたか
- 実際に遭遇したエラー内容の紹介
そもそもバージョンアップってどう進めるの？
Railsをバージョンアップするのは初めてで、何から進めるべきかもよくわかっていませんでした。
そのため、まずは過去の対応履歴などを参考にしながら全体の流れを知ることから始めました。
調べてみると大まかには下記の流れで進められていました。
①テストコードを充実させる
②バージョンアップ実施
③テストがコケている機能のリストアップ
④テストコードの修正
⑤QA実施
⑥不具合修正
今回対応したRailsバージョンアップも過去の対応を参考にしながら、同じような流れで実施を行いました。
テストコードの重要性の再認識
いざ進めてみると思っていた以上にテストコードの存在がとても重要だということがわかってきました。
テストコードの大切さは認識していたつもりですが、このような作業に関わっているとより一層身に染みて実感します。
簡単にではありますが、下記にテストコードが重要だと感じたポイントついて自分なりに記載をしておきます。
テストコードがなぜ重要なのか
新しいバージョンでは既存機能が修正されたり、非推奨機能が削除されたりなど、さまざまな変更点があります。
さまざまな変更点があるということはバージョンアップ後に意図しない動作をしてしまう機能が出てくる可能性があります。
そこで活躍するのがテストコードです。
テストコードがあることによってアプリケーションの動作が意図通りであることを確認することができます。
もしバージョンアップによって意図しない動作になり、不具合が出たとしてもテストコードがあれば、実行失敗によって検知することができます。
1個1個の機能を手動で動作確認する手間が省けるので、より効率的に不具合の検知&修正を進めることができます。
全ての機能を手作業で確認するには時間がいくらあっても足りないため、
プロダクトの規模が大きいほど、いかに効率よく検証&修正を進めていくかが重要となります。
おそらく、実際に対応してみるとテストコードの重要性をより実感できると思いますので、機会がある方はぜひチャレンジしてみてください。
テストコードだけでは検知できなかった問題
テストコードがあることで不具合の検知がしやすくなる一方で、テストコードだけでは検知できない問題もありました。
テストコードで全て検知できるわけではないとは思いつつも、実際に対応してみることで具体的にどのような問題が発生するのか解像度を上げることができました。
下記に実際、どのようなことが起こったかについても記載をしていこうと思います。
外部サービスとの連携をしているケース
外部サービスとの連携を行っている箇所の多くはテストコード上ではmock化されていました。
そのため、検証環境で実際に動作確認を行う必要がありました。
いざ動作確認をしてみると実際の外部サービス関連の処理の中で不具合が起きているというケースに遭遇しました。
これらはテストコードの実行だけでは不具合として確認できず、検知までに時間がかかってしまいました。
一部テストが無いケース
一部のパターンがテストコード上に存在しないケースもありました。
これらは一定量存在するということはある程度覚悟のうえ、後述する手動確認によるQAやモンキーテストを実施することとしました。
加えて、再発防止策として不具合検知後は、修正対応時にテストコードとしてケースを追加しておくこととしました。
どのように検知&修正を進めたのか
上述の⑤QA実施の段階で手動確認によるQAを実施することで、不具合の検知&修正を進めることができました。
ただし、全ての機能を手動で確認するには莫大な時間を要するため、
下記の観点でQAを行うか否かの判断基準を設けることとしました。
-
社内のKPI計測に関わる重要機能であること
- KPI計測に関わるログ情報を出力しているかどうか。
他のチームとも相談のうえ、重要機能についてはある程度品質をカバーすることができるであろうという想定のもと、上記の判断基準を設定することとしました。
今回の経験で手動QAで確認しておくべき勘所を少し掴めたのは良かったかなと思っています。
実際に遭遇したエラー内容の紹介
Railsバージョンアップの中でさまざまなエラーと遭遇しました。
エラーの内容と対策方法については下記のようにまとめながら共有資料として残すようにしました。
他の実装箇所でも同様のエラーが発生した際、過去対応した内容だとすぐに気付けるようにするためです。
ここからはいくつか実際に遭遇したエラー内容の紹介を簡単に紹介します。
controllerのparamsの記述方法の変更
ruby2.6からキーワード引数の挙動が変わり、リリースノートに下記の記載がありました。
キーワード引数にシンボル以外のキーを渡すとエラーが発生するようになり、修正が必要でした。
実装としてはparams.user_idと書かれているようなところをparams[:user_id]というような記述に変更することで解決しました。
参考：https://github.com/ruby/ruby/blob/1692ccaf9f49c001b18de8b7296ede3f68190ab8/NEWS
URI.escapeの廃止
URI.escapeが2.7.0では非推奨になり,3系では削除されているため、
ActionView::Template::Error: undefined method escape' for URI:Module`とエラーが出るようになっていました。
このエラーに対してはencode_www_form_componentを使うような修正をすることで解決することができました。
参考：https://docs.knapsackpro.com/2020/uri-escape-is-obsolete-percent-encoding-your-query-string
その他
他にもさまざまなエラーと遭遇しましたが、数が多く紹介しきれないため、その他のエラーとしていくつか列挙しておきます
- SendGridのライブラリ仕様変更
- FactoryBotの遅延評価周りの記述のrubocopエラー
- enumerizeの真偽値判定部分の変更
- return等によるTransaction終了の非推奨化
- 時刻の扱いの挙動変更によるテストコード上のミリ秒単位のズレ
以上となります。
簡単にではありますが、実際に遭遇したエラー内容の紹介をさせていただきました。
終わりに
Railsバージョンアップの振り返りは以上となります。
初めての経験ということで色々苦戦したこともありましたが、多くの学びがあり、自身の成長に繋がる貴重な体験をすることができました。
リリースノートやライブラリのソースコードを読みに行ったりなど、さまざまな資料に目を通すいいきっかけにもなりました。
本記事では触れませんでしたが、開発環境の準備や本番リリースの進め方など他にも様々な学びがありました。
今回触れることができなかった部分についても、別の記事として振り返ることができればと思っています。
私のようにバージョンアップ対応したことがないという方は、機会があればぜひチャレンジしてみていただければと思います。
きっと、自身の成長に繋がる経験ができるはずです。
明日は@coconala-daisaku-okadaさんによる AIスタジオのご紹介とストリーミング生成のポイント です。
ココナラでは積極的にエンジニアを採用しています。
採用情報はこちら。
カジュアル面談希望の方はこちら。
Discussion