サーバサイドエンジニアの中村です。
今回はトレタのAPIに使っているRailsのバージョンを4.1.12から4.2.7.1にアップグレードしたので、その手順について紹介いたします。
トレタのAPIでrake statsを実行した結果は以下の通りです。同じ規模感のサービスのRailsをアップグレードするときに役立てていただけたら幸いです。
+----------------------+-------+-------+---------+---------+-----+-------+ | Name | Lines | LOC | Classes | Methods | M/C | LOC/M | +----------------------+-------+-------+---------+---------+-----+-------+ | Controllers | 19554 | 16806 | 165 | 831 | 5 | 18 | | Helpers | 267 | 244 | 0 | 24 | 0 | 8 | | Models | 10685 | 6564 | 161 | 435 | 2 | 13 | | Mailers | 345 | 295 | 10 | 17 | 1 | 15 | | Javascripts | 14813 | 10032 | 16 | 1270 | 79 | 5 | | Libraries | 1316 | 992 | 24 | 89 | 3 | 9 | | Concern specs | 478 | 396 | 0 | 3 | 0 | 130 | | Controller specs | 23935 | 21178 | 1 | 3 | 3 | 7057 | | Helper specs | 147 | 118 | 0 | 0 | 0 | 0 | | Lib specs | 416 | 375 | 0 | 0 | 0 | 0 | | Mailer specs | 1958 | 1678 | 0 | 1 | 0 | 1676 | | Model specs | 11251 | 8762 | 0 | 2 | 0 | 4379 | | Request specs | 91 | 66 | 0 | 0 | 0 | 0 | | View specs | 679 | 574 | 0 | 0 | 0 | 0 | | Worker specs | 2906 | 2530 | 1 | 3 | 3 | 841 | +----------------------+-------+-------+---------+---------+-----+-------+ | Total | 88841 | 70610 | 378 | 2678 | 7 | 24 | +----------------------+-------+-------+---------+---------+-----+-------+ Code LOC: 34933 Test LOC: 35677 Code to Test Ratio: 1:1.0
サーバサイドチームのルールとして、APIの機能開発を行うときは必ずRSpecでのテストを書くようにしているので、テストが存在しないclassはほぼありません。現在、テストケースの数は約3000ケースあります。
Railsアップグレードの手順
手順は以下のように行いました。
- railsのバージョンをアップグレードする
- その他に依存するgemを
bundle updateでアップグレードする rake rails:updateを実行する- テストを全て通す
- staging環境にデプロイし、QAテストを行う
- 本番環境にデプロイ
非互換な変更や修正するべき部分の確認はRailsアップグレードガイドを参考にしました。
gemをbundle updateでアップグレードする
rails本体のバージョンをアップグレード後、テストを実行します。
この時点で1/3ぐらいのテストが落ちていたので、落ちたテストのstacktraceを確認して、関連しそうなgemをbundle updateで1つ1つアップグレードします。
ここで陥った問題として、csso-railsのバージョンを上げすぎてしまい、therubyracerで読み込めないJavaScript Codeが吐かれてしまいrake assets:precompileが失敗してしまいました。
この問題はcsso-railsのバージョンをダウングレードして回避するという方法を取りました。他の方法としては、therubyracerをmini_racerやNode.jsに置き換えると方法が考えられます。
関連するgemを全てアップグレードし終えたら、落ちるテストが10件ほどになったので、残りは1つ1つ地道に修正しました。この時点で、全てのテストが通りました。
QAテスト
staging環境にRailsアップグレード用ブランチをデプロイし、QAテストを行います。 テスト期間を2週間設けて、QAエンジニアとアプリ開発チームの協力の元、念入りにQAテストを行いました。
本番環境にデプロイ
通常のAPIのデプロイは週1回、平日昼間に行っていますが、今回のアップグレードはトレタを利用していただいている店舗さまへの影響を最小限にするために、深夜にデプロイを行いました。
EC2インスタンスの数を通常の倍に増やし、半数はアップグレードブランチのデプロイがされないようにしておき、万が一のためにすぐ切り戻せるようにしておきます。
デプロイ時、一部のテストが実行時間依存になっていることが原因でテストが落ちたことや、EC2インスタンスのネットワークが不調でデプロイ失敗など波乱がありましたが、無事デプロイ完了しました。
半日ほど様子を見て、本番で問題が起きていないことを確認後、古いコードが乗っているEC2インスタンスを削除し、全てのサーバーが4.2系のコードに切り替わりアップグレード作業が完了しました。
特にお客様からのお問い合わせも無く、安心してお店でトレタを使っていただいています。
まとめ
トレタのAPIのRailsのバージョンを1年半ぶりにアップグレードしました。 トレタのエンジニアはまだ人数も少ないこともありますが、基本的に機能開発をメインとするエンジニアしかおらず、リファクタリングや開発基盤構築をメインの職責とするエンジニアはいません。
しかし、継続的にコードを改善していく文化が根付いており、日頃から小さい改善を積み重ねていくことで、コードが大きな負債にならないように日々努力しています。今回のアップグレード作業でもほぼ問題なく、スムーズにアップグレードすることができました。
トレタでは機能開発が大好きで、継続的なコードの改善をやりたいというサーバサイドエンジニアを募集しています。トレタに興味を持たれた方はぜひこちらからご応募お願いします！
