Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Thinking about Rails upgrading
Search
y-yagi
July 20, 2017
Technology
0
90
Thinking about Rails upgrading
y-yagi
July 20, 2017
Tweet
Share
More Decks by y-yagi
See All by y-yagi
Rails 6.0 part 2
yyagi
0
3.6k
Rails 6.0 part 1
yyagi
0
3.6k
About mruby
yyagi
1
110
Rails 5.2(part1)
yyagi
1
1.6k
Rails 5.2(part2)
yyagi
0
1.7k
Ruby 2.5 on Rails 5.2
yyagi
0
120
Railsコントリビューション
yyagi
0
250
Let's Hanami
yyagi
1
670
Here Comes a Rails 5.1
yyagi
1
1.8k
Other Decks in Technology
See All in Technology
"複雑なデータ処理 × 静的サイト" を両立させる、楽をするRails運用 / A low-effort Rails workflow that combines “Complex Data Processing × Static Sites”
hogelog
3
1.7k
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
11
77k
Flaky Testへの現実解をGoのプロポーザルから考える | Go Conference 2025
upamune
1
390
PythonとLLMで挑む、 4コマ漫画の構造化データ化
esuji5
1
130
PLaMo2シリーズのvLLM実装 / PFN LLM セミナー
pfn
PRO
2
920
タスクって今どうなってるの?3.14の新機能 asyncio ps と pstree でasyncioのデバッグを (PyCon JP 2025)
jrfk
1
220
リーダーになったら未来を語れるようになろう/Speak the Future
sanogemaru
0
240
ACA でMAGI システムを社内で展開しようとした話
mappie_kochi
0
160
非エンジニアのあなたもできる&もうやってる!コンテキストエンジニアリング
findy_eventslides
3
880
SwiftUIのGeometryReaderとScrollViewを基礎から応用まで学び直す:設計と活用事例
fumiyasac0921
0
120
業務自動化プラットフォーム Google Agentspace に入門してみる #devio2025
maroon1st
0
180
自作LLM Native GORM Pluginで実現する AI Agentバックテスト基盤構築
po3rin
2
230
Featured
See All Featured
What's in a price? How to price your products and services
michaelherold
246
12k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
2.6k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
114
20k
The Invisible Side of Design
smashingmag
301
51k
Optimizing for Happiness
mojombo
379
70k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
Building Better People: How to give real-time feedback that sticks.
wjessup
368
20k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.5k
Visualization
eitanlees
148
16k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.9k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Transcript
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
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は、メンテされてない・使われて いない可能性が高いので、今後の利用を考えた方が良い
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
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がアプリ内で使われるのを避けるようにする
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
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が設定されるので使用する事のオス スメ
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
Run test again • 再度テスト実行 • ここエラーになる事はそんなに多くないはず
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
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ぱわー(真っ当な意見が多い)
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
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は、一つのバージョンアップで挙動が変わらないよう気 をつけています • しかしそれでも、(予想外に)壊れる事は往々にしてあります.
• 早めにアップグレードを試してみて、みんなでバグ踏んでいこうな