RubyとRailsを古いバージョンからアップデートした話「研究発表会vol.03〜kitazumi編〜」
はじめに
こんにちは、しくみ製作所の kitazumi です。
第3回目となる社内の研究発表会にて、弊社のゲームコミュニティサイト「BONDO」で「RubyとRailsを古いバージョンからアップデートした」という発表をしました。
「BONDO」は好評により長らく運用させていただいております。
長い故に古くなっている部分も多く、バージョンアップ関連が後回しになりがちでしたが、この度、RubyとRailsのバージョンアップを行いましたのでこちらの方でも共有させていただけたらと思います。
発表の概要
プロジェクトによってバージョンアップの作業が違ってきますので、手順については大まかな部分しか触れていません。
具体的な作業例はググっていただければ、素晴らしい記事がたくさん出てきます。
- バージョンアップしない事のリスク
- バージョンアップに必要な準備
- ハマりがちな部分
- バージョンアップに掛かった期間
以上の観点を共有する事で、他のプロジェクトでも積極的にバージョンアップを行うモチベーションになればと思います。
なんとなく面倒そう、難しそう、時間がない、という意見が多くありましたので、今回の発表でそんなイメージが払拭されれば幸いです。
バージョンアップしないことのリスク
セキュリティリスクが高まる
もともと強固なRailsのセキュリティですが、バージョンごとに更に強固にアップデートされています。この恩恵を受けない訳にはいきません。
そして古いバージョンは次第にメンテナンスされなくなり（EOL）更にリスクが高まります。
後からまとめてバージョンアップは大変
バージョン飛ばして一気にアップデートできればいいのですが、そうはいきません。順番にやらないと変更点も多くリスク大なので、まとめてやると時間がかかります。
今回まとめてバージョンアップを行ってみて、こまめにやっておけばよかったな…と痛切に感じました。
バージョンアップに必要な準備
テストカバレッジがとても重要です。
バージョンアップ作業中の不具合検知は、テストに頼る部分がとても大きいので、テストカバレッジが高い状態で行うのが理想です。
テストカバレッジが低い場合は、バージョンアップ前にテストを作成する時間を設けても良いくらいだと思います。
ハマりがちな部分
以下のあたりが分かり辛い部分です。
長くなってしまうので、詳細は添付の資料（記事の最後にリンクがあります）をご覧ください。
- Gemのバージョンアップ
- バージョンアップにより作成された config を有効にしてもいいのか？
バージョンアップに要した期間
Ruby 2.5 → Ruby 3.0
Rails 5.1 → Rails 6.1
BONDOでは上記のバージョンアップを行いました。
- 作業期間(コード上の作業)は 実質 1ヶ月かからないくらい
- staging 環境での安定動作確認&修正 に 1ヶ月程
実際には他の対応も行いながらのバージョンアップでしたので、開始から完了するまで3〜4ヶ月くらいの期間がかかりました。
1つバージョンを上げるごとに安定稼働を確認するのが一番時間がかかりますね。
発表を終えて
発表後、社内のslackでは
- dependabot を使用して gem のバージョンアップを促進している。
- この gem とこの Ruby バージョンが相性が合わなかった。
- Ruby のバージョンアップはパフォーマンスの向上に繋がる。
などの情報が交換されていて、各プロジェクトのバージョンを再確認するキッカケにもなったようでとても嬉しく感じました。
さいごに
来て頂いた方には、そんなに難しくないよ！というのが伝わった感触があり、今後の意識の変化に期待しております。
下記に資料を置いておきますので、ご興味のある方はご覧になってみてください。
まだ最新の状態とは言えないので、これからもこまめにバージョンアップを行っていきたいと思います。