dely tech blog

クラシル・TRILLを運営するdely株式会社の開発ブログです

KurashiruのRailsバージョンアップ(5.0 → 6.1)

f:id:yleek:20220404160048j:plain

こんにちは。クラシルサーバサイドのエンジニアをしておりますnegiです。

クラシルサーバサイドでは2021年10月から2022年3月にかけてRailsのバージョンアップ(5.0 → 6.1)を行なったので記事にしました。

クラシルでは2019年にRails5.0にバージョンアップして以降、バージョンアップができていませんでした。Rails5.0がEOLとなってからサポート対象外の状態になっていましたが、今回のバージョンアップによってサポート内にすることができました。

リリースは以下のように3回に分割して行いました。

  1. 5.0 → 5.1
  2. 5.1 → 6.0
  3. 6.0 → 6.1

5.0 → 6.1のように一気にバージョンアップを行うと、影響範囲が大きすぎるため想定外の問題が発生する可能性が高く、問題の切り分けも難しくなるため分割してリリースしました。

5.1 → 5.2のリリースはマイナーバージョンアップということもあり、テスト工数の削減のためにスキップしましたが、結果的にこのリリースをスキップしたことにより発生した問題もあったのでマイナーバージョンアップでもリリースのスキップすることはしない方がよかったと感じています。

やったこと

調査・修正

  • Railsと関連するgemのアップデート
  • changelogを確認し、影響のある箇所を調査・修正
  • rspecでエラーとなった箇所の修正
  • DEPRECATIONエラーが発生している箇所の修正

これらの修正のPRは合計で87件でした。PRにはどのバージョンに対する修正なのかをわかりやすくするためにバージョン毎のLabelを付与するようにしました。

コード管理

クラシルでは機能開発も並行して進んでいるため、バージョンアップ専用のブランチを作成して作業を行うとconflictが発生する可能性が高く、マージミスなどによる不具合も発生しやすくなります。また、今回のバージョンアップでは複数のバージョンを一気に上げるため、バージョン毎のコード管理が複雑になる可能性もありました。不具合によるロールバックなども考慮すると管理し切れない程複雑になると予想していました。

そこで私たちは以下のようにして対策を行いました。

  • Gemfileをバージョン毎に作成し、環境変数 BUNDLE_GEMFILE で切り替えを行うようにする f:id:yleek:20220401170457p:plain

  • バージョンアップに伴うコード修正はバージョン毎に分岐させるようにする

if Kurashiru.rails_v5_0_7_1?
  # rails 5.0.7.1 code
else
  # another rails version code
end

これにより、既存のコードを変更することなくバージョンアップ関連のコードをmasterブランチにマージすることが可能となりconflictの発生を防ぐことができます。 また、環境変数 BUNDLE_GEMFILEの変更のみでRailsのバージョンを切り替えることが可能となりました。実際、不具合によるロールバックも何度か発生しましたがこの方式のおかげでコードの管理はかなり簡易的となりスムーズにロールバックすることが可能でした。

検証

  • rspecがエラーとならないこと
  • 既存バージョンと新バージョンで動作の差分を比較
  • ステージング環境にて機能の動作確認

クラシルサーバサイドではCoverageを95%にキープできているので、ある程度の問題はrspecでカバーできるはずであると考えています。開発環境での確認では全機能を細かく確認することはせず、重要な機能のみの確認を行いました。 (Coverageをどのようにキープしているのかは別途記事にできればと思います。)

リリース方法

リリースは段階的に行いました。 まずはサーバ1台のみにデプロイをして丸1日稼働させ、これで問題がなければ全サーバにリリースしました。想定外のエラーが発生した場合はロールバックを行い、調査→修正→検証→再リリースのサイクルを行いました。これによりサービス全体への影響を最小限に抑えつつ、新バージョンのリリースを行うことができました。

まとめ

今回のRailsバージョンアップを通して感じたことは↓です。

  • リリースはマイナーバージョン毎に分けてした方が良い
  • カバレッジは高い水準でキープしておいた方が良い
  • リリース時の問題はある程度許容することが必要
  • 問題が発生することを想定して、ロールバックがしやすい環境・体制にしておくことが重要

クラシルでは過去にRailsバージョンアップを行なった実績はありましたが、今回のように複数バージョンを一気に上げるということはなかったので、Railsバージョンアップが行えたこと、サポート内にすることができてよかったです。 リリースは不具合によるロールバックを何度か行なったので決してスムーズではなかったですが、チームメンバーに調査やリリースに協力してもらいながら進めることができました。感謝です!

最後に

クラシルで行なったRailsバージョンアップについて紹介しました。Railsバージョンアップはシステムへの影響も大きいので苦労される方々も多いかと思います。参考にして頂けると幸いです。

delyではエンジニアを募集しています!少しでも興味ある方、ご応募お待ちしています! dely.jp