はじめに

Railsのバージョンアップの対応を皆さん行ったことはありますでしょうか？
今回は、6.0から6.1へバージョンアップを行ったので、対応の進め方を主にまとめています。

参考になれば、幸いです。

本記事の対象

バージョンアップ対応の進め方が知りたい人

本記事の対象外

具体的な対応策が知りたい人

早速ですが、今回どのような手順で進めたのか、以下にまとめました。

手順

バージョンアップの進め方確認
ゴールの設定
テスト方法の確認
バージョンアップ作業
テスト準備
テスト実施
本番反映

では、一つずつ詳細を見ていきましょう。

バージョンアップの進め方確認

まずは全体感をしっかり掴みましょう。個人的には、公式と以下の記事がおすすめです。

公式では、バージョンをあげることでどのような機能に修正が入ったか、また新しい機能が追加になったのかを調べるのにすごく便利です。
また、Railsのバージョンだけでなく、Gemのバージョンもあげる必要があるかもしれないですね。
ここでは、どのように進めるかさえわかれば十分です。

全体感が掴めたら、次に進みましょう。

ゴールの設定

個人的には、ここが一番大切だと思っています。

タスクを依頼された時、「このタスクでどこまで実装するべきか」を決める必要があります。決めないと、実装者と依頼者の認識にずれが生じ、出戻りする可能性があります。

バージョンアップは、とても範囲が広いです。一概にここまでがそう、ということは言えないので、しっかり依頼者とすり合わせを行いましょう。自分はどのように決めたのか、以下にまとめます。

前提

環境
- Ruby：2.7.2
- Rails：6.0.5.1

Rubyの2.7系もRails6.0系も、現時点（2024/07）で既にEOLを迎えています。

上記から考えると、Ruby・Railsもバージョンをあげる必要がありそうです。
ただ、Rails6.1は、Ruby2.5以上が必要になります。そのため、Rubyのバージョンはそこまで急いであげる必要はなさそうですね。

設定

そこで、今回の実装は以下の範囲に絞りました。

◎実装する範囲

Rails6.0 → 6.1にバージョンアップ、それに伴う修正
Railsに関連するGemのみ、バージョンアップする

◎実装しない範囲

Ruby2.7 → 3.0にバージョンアップ
Rails以外のGemのバージョンアップ

◎理由

Rubyのバージョンアップは、Railsに比べると急ぎではないため。
Gemも含めてしまうと、Railsのバージョンアップと混在してしまい、修正対象がわかりにくくなるから。

上記のように範囲を絞ると、「Rails6.1へバージョンアップする」ということが、すごく明確になったと思います。このように、タスクを振られた際に、どこまで実装するかを考えて、依頼者とすり合わせをしながら進めるのがとても大切です。

では次に、テスト方法を確認しましょう。

テスト方法の確認

バージョンアップは修正して終わり！というわけにはいきません。 システム規模に限らず、システム全体に影響する修正の場合は、テストをしっかり行うことが重要です。

ただ、今回は6.0 → 6.1 でマイナーバージョンが変わるため、そこまで大きな変更はないことが想定されます。なので、ここでは以下のことを考えるようにしましょう。

テスト範囲はどこまでにするか
どのようにテストを確認するのか
- 手動
- 自動

全てテストするに越したことはないですが、規模が大きいサービスを運用しているとなると、なかなかリソース的に難しかったりします。なので、テストはどこを確認したらokとするのか、またその範囲をどのように確認するのかの方針をチームですり合わせしましょう。

自分はどのように決めたのか、以下にまとめました。

前提

rspecで、ビジネスの根幹となる箇所はしっかりテストが配備されている
e2eテストの配備はされていない

rspecで配備はされていたので、単体テストは問題なさそう。
ただ、e2eテストが存在していなかったため、ユーザーの一連の動作で確認するテストはできない。

方針

今回は、以下の方針で進めようと思いました。

e2eテストの配備
- Autifyを使用
- 範囲は、ビジネスの根幹となる場所に絞る
残りは手動で確認

e2eテストは、Autifyを使用して、テストを自動化することに決めました。元々他チームでも導入済みだったため、スムーズに利用することができました。

ここでAutifyの使い方は、説明いたしません🙇

ビジネスの根幹となる場所に関しては、売上に直結する箇所を指しています。ユーザーがシステムを利用して売上が発生する箇所は一番重要だと思うので、そこをAutifyでテスト配備することを決めました。

ゴールが決まり、テスト方法も決まったので、いよいよ実装に入ります。

バージョンアップ作業

ここでは実際に、どのように作業を行ったかをまとめていきます。
全体感は掴んだものの、詳細はまだ調べきれていないと思うので、しっかり調査をした上で実装に取り掛かりましょう。

今回はマイナーバージョンですが、メジャーバージョンだと修正範囲が膨大になると思います。全部を調べてから実装に入ると、それだけで長期間かかってしまいそうです...。なので、ある程度は見切りをつけて、実装に取り掛かっても良いと個人的には思っています！

では早速、今回自分が行った作業を以下にまとめました。

調査

まずは、今回のバージョンアップでどのような修正が入ったか、調査します。
内容に関しては、公式が一番信頼できます。リリースノートとCANGELOGは必ず目を通して、どのような修正が入ったか、まず調査しましょう。

CHANGELOGのURLは、リリースノートに記載があります。
また、既にバージョンアップをした人の記事もすごく参考になります。以下には、自分が調べた中でのおすすめを記載しておきます。

パッチバージョンの最新化・現時点でのrspecの警告解消

いきなり6.1にすることはしません。まずは現状のバージョンで、最新のパッチバージョンまで上げます。それと同時に、rspecで以下の警告が出ていたので、同時に解消をしました。

修正できたら、PRを作成して、先にリリースします。

マイナーバージョンをあげる

いよいよ6.1にする時が来ました。
まずはGemfileに記載したrailsのバージョンを変更して、bundle update railsを行います。そうするとrailsに関係するGemしか更新はされません。

Gemfile

gem 'rails', '6.1.4'

% bundle update rails

すんなりバージョンが上がれば嬉しいですが...。
Gemのバージョンの依存関係で、エラーが出ることは、よくあるかと思います。エラーが出た場合は、対応しましょう。

対応すると、bundle update railsが通りました。ここで、一度rspecを実行してみましょう。

% bundle exec rspec

...まぁたくさんエラーが出ますよね。解消しつつ、Rails6.1に向けて、色々修正していきましょう。

テスト準備

修正が終わったら、次はテストをするために準備をしましょう。テスト方法の確認でも記載をしていますが、今回はAutifyを利用して、e2eテストを配備します。また、手動でもテストを数箇所確認する必要があるので、以下を整理します。

Autify準備
手動でテストする範囲の洗い出し

手動でテストする範囲は、扱うシステムによって異なると思います。
チーム内ですり合わせて、範囲を設定しましょう。

テスト実施

準備が終われば、いよいよテスト実施になります。
と、その前に、実装したPRはstaging環境（テスト環境）に反映して、テストを実施しましょう。

テストをしないで本番環境に反映すると、予期せぬ不具合に気づかない可能性があります。staging環境は本番環境と同じリソースを使用しているケースがほとんどなので、まずはしっかりstagingでテストをして、問題なければ、本番環境に反映を行いましょう。

本番反映

テストが終われば、いよいよ本番リリースです！
お疲れ様でした...!!

まとめ

マイナーバージョンを上げるだけとはいえ、ここまで安全に行う必要があります。
それほどフレームワークのバージョンアップは、システム全体に影響を及ぼす可能性があるので、慎重に進めるに越したことはないです。

また、こういうバージョンアップなど、ライブラリの保守はチーム内で方針を揃えて、常に最新を追えるようにしておきたいです。
緊急なアップデートがあったとしても、古くて追いつけなかったりするので...。

考え方や進め方など、参考になれば幸いです。
最後までご覧いただき、ありがとうございました。