実運用しているWebサービス「最安修理ドットコム」をRails 5.0.0.1 -> 5.1.4 に移行するためにやったこと

by flicker

こんにちは。大平(@yohira_dev)です。

今回の記事は、株式会社ジラフで開発・運用しているWebサービス「最安修理ドットコム」のRailsのバージョンをアップデートした話について書かせていただきます。


なぜアップデートが必要だったのか

「ヒカカク!」「スマホのマーケット」では、フロントエンドはES6+Reactベースで書かれていますが、最安修理ドットコムではES5ベースのjQueryとCoffeeScriptで書かれています。

このままでは、他プロダクトからエンジニアが移行してきた場合のフロントの技術スタックのキャッチアップコストが余計にかかってしまいます。

なので、3つのプロダクトでフロントエンドで使用する技術を共通化することにより、各プロダクト間でのキャッチアップコストを最小化したい、という思いがありました。

結果、Rails5.1にアップデートを行い、webpacker gemを導入することで、ES6+Reactで書けるような基盤を整えることが必要となりました。


移行前の現状把握

最安修理ドットコムは、最初はwordpressを使って実装されていましたが、2017年3月にRailsに移行しています。

ですが、かなりリソースが少ない状況下での移行であったため、ユニットテストがほぼ書かれていないまま実装・運用されていました。

移行方針

定石としては、ユニットテストのカバレッジを必要十分なパーセンテージまで上げてリグレッション(今まで動いていた機能が動かなくなること)を防いだ上で移行をするのがセオリーとなります。

しかし、最安修理ドットコムは未だ成長途中のサービスです。フレームワークのバージョンアップそれ自体は新しい機能をリリースしているわけではないので、外から見た価値向上に貢献しているわけではありません。

フレームワーク自体のバージョンアップは迅速に済ませ、ユーザーに貢献していける新機能を一つでも多く開発していきたい、というのもビジネス上のニーズとしてあるわけです。

幸いにも、

  • ソースコード自体の量がそれほど多くない
  • Rails5.0.0.1 -> Rails 5.1.4というあくまでマイナーバージョンアップなので破壊的な変更は少なそう

という要素もあったので、以下の方針で移行を進めることにしました。

直面した問題

1.Rails 5.1から、idに暗黙に期待する型が変わっているので、migrationに失敗する

Rails 5.1以前は、Modelのidはintegerが暗黙的に設定されていましたが、Rails 5.1 以降はBigIntになります。

なので、Rails 5.1以前のマイグレーションで定義されたModelに対して、Rails 5.1 以降で定義されたModelにreferencesで外部キー参照を追加するマイグレーションスクリプトを書くとエラーになります。

# 移行前に作成したHogeモデルを参照するモデルAwesomeModelsのマイグレーション
class CreateAwesomeModels < ActiveRecord::Migration[5.1]
def change
create_table :awesome_model do |t|
t.references :hoge # 暗黙にBigIntを期待するが、テーブルはIntegerなのでエラー
t.timestamps
end

end
end

一旦、下記の書き方でエラーを回避することにしました。

class CreateAwesomeModels < ActiveRecord::Migration[5.1]
def change
create_table :awesome_model do |t|
t.integer :hoge_id, null: false # 型を明示的に指定
t.timestamps
end
add_foreign_key :awesome_models, :hoges
end
end

恒久的には、既存Modelのidの型をBigIntに変えることが望ましいかと思われますが、一旦先送りとしています。

2.redirect_to :back の廃止

Rails 5.1から、redirect_to :back という書き方が廃止されエラーになるようになっています。Rails 5.1以降では、redirect_back というメソッドを使用する必要があります。

この書き方をしている部分に関しては個別に修正対応が必要でした。

結果

上記の問題に対応しつつ、2週間程度でリリースすることができ、現在は安定稼働できています。

より品質の良いサービスにしていくために

新規に追加する機能に関してはRSpecのテストを書いてPull Requestを送信するようにチーム内でルール化しています。

カバレッジ100%まで達成できてはいませんが、

  • テストを書く習慣がつく
  • 「プロダクトコードはテストコードがついてはじめて完成する」という認識をチーム内で持てるようになる

という効果を実感しています。

また、既存ソースコードに関しても、新規開発とは別途にユニットテストを書く時間を確保し、長期的な目線でプロダクトの品質を維持・向上させていくことを考えています。

告知

株式会社ジラフでは一緒にプロダクトを開発していく仲間を正社員・業務委託問わず幅広く募集中です。