Thinking about Rails upgrading

Thinking about Rails upgrading @y-yagi

About • Rails upgradingを行う際にやっていること・考えている事をまとめた資料です • あくまで個人の感想です

Upgrading Flow 1. Bundle update Rails 2. Run test 3.
Update config 4. Run test again 5. Fix deprecate message 6. Finally run the test again

Bundle update Rails • 何はともあれまずは “bundle update rails” • しかし依存しているgemでrailsのバージョンロックが入っている事
が多く、まずここで時間がかかる • 片っ端から更新のPRを送る ◦ が、その前に、そもそもそのgem本当に必要か再度考える

Bundle update Rails • そのgem本当に必要ですか? • インストールした際は必要だったとしても、その後要件が変わったりして実は不要になったgemが残ってるかもしれない • 便利かと思っていれてみたが、実はそんなに便利ではなかった(要
件が合わなかった)gemが残ってるかもしれない • Rails本体で同じ機能が提供された事により、不要になった可能性もある(e.g. quiet_assets)

Let's clean the Gemfile

Bundle update Rails • Railsのアップグレードの際にgemの掃除も行う ◦ 実際のPRアップグレードのPRとは別で投げたりする • Railsのアップグレードで辛い事の多くはgemの更新(個人の感想) なので、今後の事も考えて負担を減らしていく
• 見直しをした結果、本当に必要なgemにだけ更新のPRを送る ◦ それでも多いかもしれないが、そこは頑張る

Bundle update Rails • よく使われているgemであれば、既に誰かがPRを送っている可能性が高い • 逆にいうと、Railsが正式リリースされても対応のPRが無い・PRがあっても放置されているようなgemは、メンテされてない・使われていない可能性が高いので、今後の利用を考えた方が良い

Run test • 最初のテスト実行 • ここで落ちる場合、Railsのバグを踏んだ、private APIを使用していてそれが壊れた、gemが壊れた、等々色々な要因がありえる • ここは頑張って一つずつ対応していくしか無い
• そもそもテストが無いプロジェクトは、色々頑張っていきましょう

public API / private API • Railsはpublic API(ユーザが使用して良いAPI)とprivate API(ユーザが使用してはいけないAPI)が明確にわかれている
• public APIはRails API doc にのっているAPI、それ以外は基本 private API • 例えばActive Recordではwhereはpublic APIだが、where!は private API ◦ なのでwhere!は使っては駄目ですよ ◦ Arelも同様

public API / private API • public APIは一つのバージョンアップ(major, minor問わず)で挙動が変わる事は無い
◦ public APIについては、必ず既存の挙動をdeprecationにしてから変えるようにしてる ◦ 一部例外あり

public API / private API • どうしても挙動が変わってしまうAPIについては、A Guide for Upgrading
Ruby on Rails に載る(はず) • それ以外のpublic APIの挙動が変わっていたらそれはバグなので、issueで報告する

public API / private API • private APIを多用している場合のアップグレードは大変 ◦ そもそもメソッドが無くなっている場合もあったりで、気付くのが大変
• Railsの機能を拡張するgemでprivate APIを使うのは仕方無いが、普通のRailsアプリではprivate APIを使用しなくてもどうにかなるはず

public API / private API • どうしてもprivate APIが必要な場合は、その部分だけ切り出して gemにする、他のファイルと混ぜない(モンキーパッチである事が明確にわかる管理にする)ようにきをつける
• または、private APIをpublic APIにするようRails側にPRを送る ◦ 一旦public APIに出来ればこっちのもん • 最大限private APIがアプリ内で使われるのを避けるようにする

Update config • テストが通ったら、新しいconfigを適用していく • 新しいconfigについては RailsDiff を見る、手元で元のオプションと同じオプションを指定してrails newして既存のアプリとのdiffを
とる、等をして確認すると良いと思います

Update config • app:updateは使ってない • app:updateは色々と問題がある(rails newで指定したオプションを考慮しない、configのappendが出来ない等) ◦ 多少直したい気持ちはある
◦ Do not generate unused components contents in app:update task

Update config • Rails 5.1以降であれば load_defaults を使えば勝手に Railsオススメのconfigが設定されるので使用する事のオススメ

Run test again • 再度テスト実行 • ここエラーになる事はそんなに多くないはず

Fix deprecate message • deprecateメッセージを片っ端から潰していく • deprecateメッセージに代わりに使うべきメソッド・configが含まれている筈なので、基本的にはそれに従う ◦ "without
replacement"なケースもあるが、それで本当に困る事は滅多に無い筈

Fix deprecate message • 対応が広範囲に渡る修正は別PRにする、バックポートしても問題無い対応は別PRにして古いコードに入れる、等を行う • アップグレードのPRが大きくなり過ぎないよう気をつける ◦ 無理に一つのPRに全部を入れない
• また、既存のコードを壊す可能性がある対応も別PRにする(DB周りは特に)

Fix deprecate message • Railsのバージョンがrcの場合は少し様子を見る事もある ◦ rcリリース後にdeprecateだったのがdeprecateじゃなくなるケースもたまにあるので ◦ e.g. Remove
implicit coercion deprecation of durations ◦ DHHぱわー(真っ当な意見が多い)

Finally run the test again • 最後のテスト実行 • ここエラーになるケースはそんなに多くない筈

Finish 後は震えながら本番にリリースするだけ

After release • エラーが置きないか気にするのは当然として、性能劣化もチェックする • 出来ればリリース前にチェック出来ると良い、 • 性能確認する環境が無い場合はリリース後注視する

After release • 性能劣化はちょいちょいおきる • 最近だと ◦ Upgrading from Rails
5.0.0.1 to 5.0.1 increases import from... ◦ 5.0.0 -> 5.0.1 mysql foreign_keys is crazy slow

After release • Rails側でパフォーマンスチェックの為の仕組みが無い ◦ RubyBench - Long Running Ruby
Benchmark とかあるが、公式では無い • これについてはアプリ側で意識するしか現状無い

Conclusion • Rails upgradingを行う際にやっていること・考えている事についてお話しました • 最近のRailsは、一つのバージョンアップで挙動が変わらないよう気をつけています • しかしそれでも、(予想外に)壊れる事は往々にしてあります.
• 早めにアップグレードを試してみて、みんなでバグ踏んでいこうな

Thinking about Rails upgrading

Thinking about Rails upgrading

y-yagi

More Decks by y-yagi

Other Decks in Technology

Featured

Transcript