たいへんな状況になってしまいまいましたが、皆様お元気でしょうか？ EY-Officeは従来から開発は自宅・オフィスで行っていたので変化無しですが、教育系のお仕事は延期になってしまい時間に余裕ができました。以前から在宅勤務を行っているネット企業の方は通常のアクティビティかもしれませんが、通勤が無くなり時間に余裕ができて方も多いかと思います。
さて、こんな時は
- 将来に備えて新しいテクノロジーを学ぶ
- 家族との過ごす時間を増やす
- ついつい後回しになっていた仕事を片付ける
などあると思いますが、私は後回しになっていたRuby on Railsで書かれたサービスのRuby on Rails等のバージョンアップを行いました。
昨年夏にRails6.0 がリリースされ、Ruby on Rails のメンテナンスポリシー によるとセキュリティ問題の修正も 6.0.Z と 5.2.Z しかサポートされていません。 Rails 4.2 で運用しているのはヤバイ状況になってしまいました。
Rails 4.2 → 5.0 → 5.2
Rails 4.2 から 5.0 へのアップグレードはネット系上にたくさんの情報があり、それらを参考に行う事で比較的容易でした。 modelのベースクラスにするActiveRecordにする、before_filter が before_action に変わった、migrationにバージョン番号を追加するなど、単純な書き換えばかりでした。
Railsのメージャーアップデートでは非互換なアップデートがまま起きます、それを検出するのはテストの重要な役割の一つです。
さて、このサービスではユニットテストは RSpec、E2Eテストは Cucmber、管理画面のE2Eテストは RSpec Feature を使っています。RSpecは問題ありませんでしたが、Cucmber には苦しめられました !!
Transform が無くなった !
Cucumber 3.0 から Transformがなくなりました。Upgrading to Cucumber-Ruby 3.0.0 によると、Transform は無くなるので ParameterType を使えと書いてあります。 ParameterType は CucumberのStepの記述をスマートに出来る機能のようです。
しかし、ParameterType には Transform の全ての機能があるわけではないのです！
Transform /4日後/ do |step_arg|
(Time.now.since 4.day).strftime("%m月%d日")
endと定義すると、feature に かつ 希望日から4日後を選択する と書くと選択肢(selectタグ)にある 3月21日 が選択されます。
しかし、ParameterTypeを使おうとすると4日後をサポートする専用の step を書かないといけません。
何か上手い使い方がないかと Google で Cucumber ParameterType を検索しても有用な記事は出ませんでした。GitHubで検索しても Ruby で ParameterType を使っているコードは 1 つしかありませんでした !!
もう、Ruby では Cucmber は使われていないのでしょうか？
さらに、Cucmber 2.X を使い続けるという選択肢はありませんでした。Rails 5.2(5.1)にするとGemの依存関係から cucumber-rails 1.9以上を使う必要があり、そうなると cucumber は 3.0以上ななります・・・・
遅くなった !!
Cucmber の実行時間は 2分 が 6分、なんと3倍も時間がかかります !!
RSpec Feature は 39秒 が 44秒なので、ほぼ同じなのに。
テストの下位レーヤーは Cucmber / RSpec Feature どちらも Capybara + Phantomjs + Puma なので、これらの問題ではないようです。Cucumber の問題かもしれないですが、今のところ追求していません。
今回のTransform が無くなった件もあるので、もし時間とやる気が起きれば、Turnip に置き換えてしまおうかと思いました。TurnipならCucumberのfeaturesはほぼそのまま使えるし、下位レーヤーは RSpec Feature なのでメンテコストも下がるかも・・・
Ruby 2.5 → 2.6
ここは、全く問題ありませんでした。ついでに 2.7 に上げてみたのですがキーワード引数の仕様変更によるワーニングが多数発生しました、しかもアプリではなくRailsの依存ライブラリーの中で発生していたので今回は諦めました。Ruby 2.7 は Rails 6.0対応の時にしようかと思います。
PostgreSQL 9.6 → 12.2
PostgreSQLの問題はありませんでした。ただしアプリの中で高速化の為に直接SQLを書いているカ所があるのですが、そこで created_at,updated_at を設定してないのがエラーになってしまうので対応しました。
まとめ
前々から気になっていたことが対応出来て、心の隅にあったモヤモヤが一つ解決しました。もし時間に余裕の生まれた開発者は既存コードのメンテナンスなど行ってはどうでしょうか。
