Thinking about Rails upgrading

Slide 1

Slide 1 text

Thinking about Rails upgrading @y-yagi

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

Let's clean the Gemfile

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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も同様

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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