あなたとRails

Kaigi on Rails 2022 Oct 21, 2022

Transcript

1. あなたとRails Kaigi on Rails 2022 Oct 21, 2022 Yasuo Honda @yahonda
2. • Yasuo Honda @yahonda ◦ Active Record Oracle enhanced adapter maintainer ◦ Rails committer ◦ https://github.com/yahonda ◦ https://twitter.com/yahonda self
3. https://rubyonrails.org/2022/5/23/welcome-to-core-and-committers
4. https://rubyonrails.org/community
5. 質問: “OSSコントリビューションの初手で おすすめの方法は?” Note: 2018年11月のRailsdm Podcast #6 での発言より。音源が存在しないため発 言は私の記憶の限りです。
6. 回答: “まず、使っているRailsのバージョンを 最新に上げること” Note: 2018年11月のRailsdm Podcast #6 での発言より。音源が存在しないため発 言は私の記憶の限りです。
7. この回答になった理由を話します
8. • Railsのメンテナンスポリシーを理解する • アプリケーションのRailsバージョンを上げる ◦ 最新に上げる ◦ 最新stable branch(7-0-stable)にする ◦ main branchで試す • Railsにpull requestを送る ◦ bug fixをする ◦ new featureを追加する • あたらしい取り組み 話すこと
9. Railsのメンテナンスポリシーを 理解する
10. • The Rails communityが、どのようなメンテナンスをどのバージョンに対 して行うかを宣言したもの ◦ New Features: main branch (7.1.0.alpha) ◦ Bug Fixes: 7.0.Z ◦ Security Issues: 6.1.Z ◦ Severe Security Issues: 7.0.Z, 6.1.Z, 6.0.Z • サポートマトリクスではありません ◦ 静的な状態を示すものではありません Railsのメンテナンスポリシー
11. https://guides.rubyonrails.org/maintenance_policy.html
12. よくある質問: “Rails 6.1はRuby 3.1をサポートしていますか?”
13. 私の回答: Ruby 3.1リリース時点で、Rails 6.1.z は”Security issues”対応段階であるため、 Rails 6.1に”Bug fixes”は行いません(行う宣 言はしていません) Note: 動くかどうかではなく、動く状態を保つために行うメンテナンスという行動に主眼 が置かれています
14. • Rails 6.1.5でRuby 3.1のdefaul gemであるpsych 4対応が入りました • 興味のある方は、”Ruby 3.1 on Rails”を参照ください ◦ https://gist.github.com/yahonda/2776d8d7b6ea7045359f38c 10449937b Rails 6.1とRuby 3.1の補足
15. https://rubyonrails.org/2022/9/9/Rails-7-0-4-6-1-7-6-0-6-have-been-released
16. “Please note that the 6.0.x and 6.1.x release series are no longer supported for bug fixes. These releases are a best effort, so please upgrade as soon as possible.” Rails 7.0.4, 6.1.7, and 6.0.6 have been released!
17. • Rails 6.0.zと6.1.zは”Severe Seciruty Issues”、”Security issues”対 応の段階です • 今回のRais 6.0.6と6.1.7は”Bug Fixes”範囲のメンテナンスです • “best effort”は、メンテナンスポリシーの範囲を超えるものです ◦ ベストエフォートより、例外対応に近い ◦ “best effort”に依存したり、期待したりしないでください • “Bug fixes”が行われるRails 7.0.4へのアップグレードを推奨します リリースアナウンスメントの解釈
18. アプリケーションの Railsバージョンを最新に上げる
19. • オフィシャルガイド ◦ https://guides.rubyonrails.org/upgrading_ruby_on_rails.html • そのほか多くのアップグレードに関する技術記事があります アプリケーションのRailsバージョンを7.0.4に
20. • メンテナンスポリシーはissueにも関連します ◦ https://github.com/rails/rails/issues • 今、Rails 6.1.z以下で期待しない動作が報告された場合 ◦ mainまたは7-0-stableブランチで、期待しない動作が発生するか の切り分けが期待されます ◦ Rails 6.1.zにアップグレードして、期待しない動作への変化が起きて も、それがsecurity issueでない限り、対応は6-1-stableには入り ません メンテナンスポリシーとissueの関連
21. “If you can still reproduce this error on the 7-0-stable branch or on main, please reply with all of the information you have about it in order to keep the issue open.” rails-bot https://github.com/rails/rails/commit/3ccee2c6467220fac92b99dc21cbce 24df880566
22. • メンテナンスポリシーはpull requestにも関連します • New features : `main`ブランチのみに入ります ◦ そのうち7.1.0としてリリースされます(厳密には正しくない表現) • Bug fixes:`7-0-stable`ブランチにバックポートされます ◦ いずれ7.0.5としてリリースされる予定 ◦ 通常、バックポートはcommit権限を持ったメンバーが行います ◦ まずmainにpull requestを送り、バックポート依頼してください ◦ 最初から7-0-stableブランチをターゲットにしたpull requestは送らな いでください メンテナンスポリシーとpull requestの関連
23. • New contributorsへの最初の一手として利用されるラベル • Ruby on Railsではあまり活用されていません ◦ 比較的成熟したフレームワークであること ▪ 発生する問題が難しくなってきたこと ◦ low hanging fruitも少なくなりつつあること ▪ CIで、typoやwarningはCIがfailするようになりました ▪ Activeなcontributorによってすぐ修正されます “good first issue”
24. みんなの環境で発生する問題だけでなく、 ”あなたの”課題を解決しましょう
25. アプリケーションの Railsを最新stableブランチ(7-0-stable) にする
26. • いずれリリースされるであろうRails 7.0.5に最も近い状態のブランチ • Bug fixesのみが含まれ、new featuresや意図したbreaking changesは 含みません • 定期的にユニットテストやMigrationを実行してみましょう • Gemfile.lockも毎回更新する必要があります ◦ 7-0-stableブランチにはbackport commitsが入ります • Gemfile.lockのrevisionをログに残すことをおすすめします 7-0-stableとは
27. Rails 7.0.4から7–0-stableへのdiff % git diff Gemfile -gem "rails", "~> 7.0.4" +gem "rails", github: "rails/rails", branch: "7-0-stable" % git diff Gemfile.lock +++ b/Gemfile.lock @@ -1,5 +1,7 @@ -GEM - remote: https://rubygems.org/ +GIT + remote: https://github.com/rails/rails.git + revision: 5bebef36ade9103b1e4ebcfdafcf0c7361f75c45 + branch: 7-0-stable
28. https://github.com/rails/rails/compare/v7.0.4...7-0-stable
29. • `git bisect`で、the first “bad” commitを特定します • そのcommitの元となったpull requestを特定します • 可能であれば、Bug report templatesを使って再現コードを書き、新規 issueをオープンします • https://github.com/rails/rails/tree/7-0-stable/guides/bug_rep ort_templates • 少なくとも、Commitの元となったpull requestにコメントします • 何も問題が起きないのが一番です 7-0-stableを利用して問題が発生したら
30. • Rails 6.1.5で報告されたregression • https://github.com/rails/rails/issues/43168 • 発生条件 ◦ SQLite adapter ◦ `ActiveRecord::Migration[6.0]` ◦ `reference`または`belongs_to`の`integer`が`bigint`として作 成される Patchバージョン間でのregression例
31. • きっかけとなったbackport (Rails 6.1.4とRails 6.1.5の間) ◦ https://github.com/rails/rails/commit/df475877efdcf74d7 524f734ab8ad1d4704fd187 • これらのpull requestsで修正されました ◦ https://github.com/rails/rails/pull/43295 ◦ https://github.com/rails/rails/pull/42350 • regressionがないのが理想ですが、再現ケースつきのissueやpull requestによってcontribution可能という考え方もあります Patchバージョン間でのregression例
32. アプリケーションの Railsをmainブランチで試す
33. • いずれリリースされるであろうRails 7.1.0に最も近い状態のブランチ • new features, deprecation warnings, breaking changesを含む • 以下の2点においてstableブランチに比べて不安定 ◦ CIがredになることもある(意図しない不安定さ) ▪ https://buildkite.com/rails/rails/builds?branch=main ◦ Breaking changeやrevertがある(意図した不安定さ) mainブランチとは
34. https://rails-hosting.com/2022/#what-versions-of-rails-are-you-using-in-your-applications
35. Rails 7.0.4からmainへのdiff % git diff Gemfile -gem "rails", "~> 7.0.4" +gem "rails", github: "rails/rails", branch: "main" % git diff Gemfile.lock +++ b/Gemfile.lock @@ -1,5 +1,7 @@ -GEM - remote: https://rubygems.org/ +GIT + remote: https://github.com/rails/rails.git + revision: caf94136045f79b1d9103ebf17fc74b7ff7f8727 + branch: main
36. • 3rd party gems対応 ◦ `bundle install`が通るまでが一つのハードル ◦ Railsのバージョンに上限を設けているgemもあります ◦ Private APIやbreking changeに依存する場合は変更が必要 • Note: mainの利用を、みなさんに推奨するものではありません ◦ おそらくチームとしての体制が必要になります ◦ そのぶん、多くのcontributionやフィードバック機会が生まれたり、 mainブランチの新機能をいち早く利用できたりします main branchを試す
37. • Pull requestを送り、そのbaseブランチをGemfileに設定します • まずは、gemメンテナーのメンテナンスポリシーを尊重しましょう ◦ すぐにマージされる場合もあるし、正式にリリースされるまでマージし ない、あるいはマージしてもしても当面リリースしないなどがあります ◦ Railsのmainの変更はrevertされる可能性もあります 3rd party gemsにRails main対応が必要な時
38. • Rails 7.1.0リリース前に7.1.0.betaや7.1.0.rcが出るはずなので、ぜひ試し てください ◦ RC: Release Candidate • 通例通りなら、7-1-stableブランチが切られてrc1がでるはずです ◦ RCはbreaking change/unexpected behaviorをdeprecation warningなしでrevertできる最後の機会です ◦ “That ship has sailed.” RCや Betaを試す
39. Railsにbug fixの pull requestを送る
40. 想定する質問: “RailsはCIが回っているのに、どうして bug/regressionが発生するのですか?”
41. 回答: “Railsのテストに含まれないRailsの振る舞い (untested behaviors)があるから” もちろんこれが全てではありません。単なるregressionもあります
42. • 書かれているAPI : Public API ◦ メジャーバージョン、またはマイナーバージョン間でbreaking changeがある場合は、deprecation cycleが入ります ◦ パッチバージョンで意図的なbreaking changeは入りません • 書かれていないAPI : Private API • Rubyのpublic, private, protectedとの関連 ◦ public methodでも :nodoc: があるとPrivate API ◦ private, protectedは全てPrivate API api.rubyonrails.org
43. https://api.rubyonrails.org/
44. “1.1.1　Hyrumの法則 あるAPIに十分な数のユーザーがいるとき、 APIを作った者自身が契約仕様として何を約 束しているかは重要ではない。作られたシステ ムが持つあらゆる観察可能（observable）な 挙動に関して、それに依存するユーザーが出 てくるものである。” Titus Winters、Tom Manshreck、Hyrum Wright　編、竹辺 靖昭　監訳、久富木 隆一　訳 『Googleのソフトウェアエンジニアリング』(オライリー・ジャパン、2021年)
45. • https://github.com/rails/rails/pull/45156 ◦ whereの第一引数に空文字が入った時、`WHERE`のみが追加され た無効なSQLとなる • Rails committerになった直後にレビューしたpull request ◦ 最終的にマージせずにcloseしたこともあり印象深い ◦ #45156は、pull requestの説明、振る舞いの変化のきっかけとなっ た pull requestの調査など適切な説明内容でした Untested bahaviorsの例
46. #45256で報告されたwhereの振る舞いの変化 - Rails 6.0.zまで -> whereの第一引数に空文字が入った時、 `WHERE`句のない全件検索と なる ``` puts User.where("", {}).to_sql # => SELECT "users".* FROM "users" ``` - Rails 6.1.0以降 -> whereの第一引数に空文字が入った時、 `WHERE`のみが追加された無 効なSQLとなる ``` puts User.where("", {}).to_sql # => SELECT "users".* FROM "users" WHERE ``` - 対応方法は User.all
47. • この振る舞いの変更のきっかけ ◦ https://github.com/rails/rails/pull/39784 ◦ 2020年10月にmainにマージされ、Rails 6.1.0としてリリース ◦ Rails 6.0.zから6.1.0の間で発生したregressionとも言えます • #45156 オープン時点でのBug fixes対象はRails 7.0.z ◦ Rails 6.1.zがBug fix対象期間、同様の事象の報告はなし ◦ Rails 6.1.0からRails 7.0.3まで、この振る舞いとなっていました • #45256をマージすると、#39784に依存した未知のuntested behavior のregressionを起こす可能性がありました #45256の背景とcloseを選択した理由
48. • Railsのユニットテストを全部見て、アプリケーションに書かれていない振 る舞いを探すのは困難です • (仮にそれができたとしても)その振る舞いのユニットテストのみを追加する pull requestを説得するのも困難です • フレームワークにその上位のアプリケーションの振る舞いを全てテストす るのは不可能だし、適切な方向性ではないと考えています Untested behaviorsへの現実的な対応
49. Railsにnew featureの pull requestを送る
50. よくする質問: “ユースケースはありますか”
51. アドバイス: 最新のRailsを利用することで、実 際のユースケース(あなたの使い方)を実装した り、試したりしやすくなるはずです。それを元に 説明してみてください 古いバージョンのRailsに新機能を追加しても、新しいRailsのコードベースが変わってい て、そのままcherry pickできない可能性が高まります
52. https://speakerdeck.com/yahonda/how-to-get-your-pull-requests-merged
53. あたらしい取り組み
54. https://speakerdeck.com/eileencodes/the-success-of-rails-ensuring-growth-for-the-next-100-years
55. https://rubyonrails.org/2022/6/13/rails-discord-server-is-now-open-to-the-public
56. • Pull requestが自動的にクローズされなくなりました ◦ https://github.com/rails/rails/pulls ◦ Issueは一定期間変更がないと自動クローズされます • Contributors情報交換のためにRails Discord Serverができました ◦ #contributors チャンネル • https://discuss.rubyonrails.org も引き続き存在します あたらしい取り組みの例
57. https://discord.gg/d8N68BCw49 Rails Discord Server
58. • Railsのpull requestに関して質問がある方は: • Rails / OSS パッチ会 ◦ 毎月1回 午後5時から午後7時まで、次回は10月25日 • Asakusa.rb ◦ 毎週火曜日 午後7時30分から • 西日暮里.rb ◦ 毎月最終月曜日 午後8時から、次回は10月31日 Questions?
59. Thank you for attending. Upgrade your Rails today!