あなたとRails - Speaker Deck

Slide 1

Slide 1 text

あなたとRails Kaigi on Rails 2022 Oct 21, 2022 Yasuo Honda @yahonda

Slide 2

Slide 2 text

● Yasuo Honda @yahonda ○ Active Record Oracle enhanced adapter maintainer ○ Rails committer ○ https://github.com/yahonda ○ https://twitter.com/yahonda self

Slide 3

Slide 3 text

https://rubyonrails.org/2022/5/23/welcome-to-core-and-committers

Slide 4

Slide 4 text

https://rubyonrails.org/community

Slide 5

Slide 5 text

質問: “OSSコントリビューションの初手でおすすめの方法は?” Note: 2018年11月のRailsdm Podcast #6 での発言より。音源が存在しないため発言は私の記憶の限りです。

Slide 6

Slide 6 text

回答: “まず、使っているRailsのバージョンを最新に上げること” Note: 2018年11月のRailsdm Podcast #6 での発言より。音源が存在しないため発言は私の記憶の限りです。

Slide 7

Slide 7 text

この回答になった理由を話します

Slide 8

Slide 8 text

● Railsのメンテナンスポリシーを理解する ● アプリケーションのRailsバージョンを上げる ○ 最新に上げる ○ 最新stable branch(7-0-stable)にする ○ main branchで試す ● Railsにpull requestを送る ○ bug ﬁxをする ○ new featureを追加する ● あたらしい取り組み話すこと

Slide 9

Slide 9 text

Railsのメンテナンスポリシーを理解する

Slide 10

Slide 10 text

● 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のメンテナンスポリシー

Slide 11

Slide 11 text

https://guides.rubyonrails.org/maintenance_policy.html

Slide 12

Slide 12 text

よくある質問: “Rails 6.1はRuby 3.1をサポートしていますか?”

Slide 13

Slide 13 text

私の回答: Ruby 3.1リリース時点で、Rails 6.1.z は”Security issues”対応段階であるため、 Rails 6.1に”Bug ﬁxes”は行いません(行う宣言はしていません) Note: 動くかどうかではなく、動く状態を保つために行うメンテナンスという行動に主眼が置かれています

Slide 14

Slide 14 text

● 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の補足

Slide 15

Slide 15 text

https://rubyonrails.org/2022/9/9/Rails-7-0-4-6-1-7-6-0-6-have-been-released

Slide 16

Slide 16 text

“Please note that the 6.0.x and 6.1.x release series are no longer supported for bug ﬁxes. 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!

Slide 17

Slide 17 text

● 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 ﬁxes”が行われるRails 7.0.4へのアップグレードを推奨しますリリースアナウンスメントの解釈

Slide 18

Slide 18 text

アプリケーションの Railsバージョンを最新に上げる

Slide 19

Slide 19 text

● オフィシャルガイド ○ https://guides.rubyonrails.org/upgrading_ruby_on_rails.html ● そのほか多くのアップグレードに関する技術記事がありますアプリケーションのRailsバージョンを7.0.4に

Slide 20

Slide 20 text

● メンテナンスポリシーは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の関連

Slide 21

Slide 21 text

“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

Slide 22

Slide 22 text

● メンテナンスポリシーはpull requestにも関連します ● New features : `main`ブランチのみに入ります ○ そのうち7.1.0としてリリースされます(厳密には正しくない表現) ● Bug ﬁxes:`7-0-stable`ブランチにバックポートされます ○ いずれ7.0.5としてリリースされる予定 ○ 通常、バックポートはcommit権限を持ったメンバーが行います ○ まずmainにpull requestを送り、バックポート依頼してください ○ 最初から7-0-stableブランチをターゲットにしたpull requestは送らないでくださいメンテナンスポリシーとpull requestの関連

Slide 23

Slide 23 text

● New contributorsへの最初の一手として利用されるラベル ● Ruby on Railsではあまり活用されていません ○ 比較的成熟したフレームワークであること ■ 発生する問題が難しくなってきたこと ○ low hanging fruitも少なくなりつつあること ■ CIで、typoやwarningはCIがfailするようになりました ■ Activeなcontributorによってすぐ修正されます “good ﬁrst issue”

Slide 24

Slide 24 text

みんなの環境で発生する問題だけでなく、 ”あなたの”課題を解決しましょう

Slide 25

Slide 25 text

アプリケーションの Railsを最新stableブランチ(7-0-stable) にする

Slide 26

Slide 26 text

● いずれリリースされるであろうRails 7.0.5に最も近い状態のブランチ ● Bug fixesのみが含まれ、new featuresや意図したbreaking changesは含みません ● 定期的にユニットテストやMigrationを実行してみましょう ● Gemfile.lockも毎回更新する必要があります ○ 7-0-stableブランチにはbackport commitsが入ります ● Gemfile.lockのrevisionをログに残すことをおすすめします 7-0-stableとは

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

https://github.com/rails/rails/compare/v7.0.4...7-0-stable

Slide 29

Slide 29 text

● `git bisect`で、the ﬁrst “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を利用して問題が発生したら

Slide 30

Slide 30 text

● 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例

Slide 31

Slide 31 text

● きっかけとなった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例

Slide 32

Slide 32 text

アプリケーションの Railsをmainブランチで試す

Slide 33

Slide 33 text

● いずれリリースされるであろう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ブランチとは

Slide 34

Slide 34 text

https://rails-hosting.com/2022/#what-versions-of-rails-are-you-using-in-your-applications

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

● 3rd party gems対応 ○ `bundle install`が通るまでが一つのハードル ○ Railsのバージョンに上限を設けているgemもあります ○ Private APIやbreking changeに依存する場合は変更が必要 ● Note: mainの利用を、みなさんに推奨するものではありません ○ おそらくチームとしての体制が必要になります ○ そのぶん、多くのcontributionやフィードバック機会が生まれたり、 mainブランチの新機能をいち早く利用できたりします main branchを試す

Slide 37

Slide 37 text

● Pull requestを送り、そのbaseブランチをGemﬁleに設定します ● まずは、gemメンテナーのメンテナンスポリシーを尊重しましょう ○ すぐにマージされる場合もあるし、正式にリリースされるまでマージしない、あるいはマージしてもしても当面リリースしないなどがあります ○ Railsのmainの変更はrevertされる可能性もあります 3rd party gemsにRails main対応が必要な時

Slide 38

Slide 38 text

● 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を試す

Slide 39

Slide 39 text

Railsにbug ﬁxの pull requestを送る

Slide 40

Slide 40 text

想定する質問: “RailsはCIが回っているのに、どうして bug/regressionが発生するのですか?”

Slide 41

Slide 41 text

回答: “Railsのテストに含まれないRailsの振る舞い (untested behaviors)があるから” もちろんこれが全てではありません。単なるregressionもあります

Slide 42

Slide 42 text

● 書かれている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

Slide 43

Slide 43 text

https://api.rubyonrails.org/

Slide 44

Slide 44 text

“1.1.1　Hyrumの法則あるAPIに十分な数のユーザーがいるとき、 APIを作った者自身が契約仕様として何を約束しているかは重要ではない。作られたシステムが持つあらゆる観察可能（observable）な挙動に関して、それに依存するユーザーが出てくるものである。” Titus Winters、Tom Manshreck、Hyrum Wright　編、竹辺靖昭　監訳、久富木隆一　訳『Googleのソフトウェアエンジニアリング』(オライリー・ジャパン、2021年)

Slide 45

Slide 45 text

● https://github.com/rails/rails/pull/45156 ○ whereの第一引数に空文字が入った時、`WHERE`のみが追加された無効なSQLとなる ● Rails committerになった直後にレビューしたpull request ○ 最終的にマージせずにcloseしたこともあり印象深い ○ #45156は、pull requestの説明、振る舞いの変化のきっかけとなった pull requestの調査など適切な説明内容でした Untested bahaviorsの例

Slide 46

Slide 46 text

#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

Slide 47

Slide 47 text

● この振る舞いの変更のきっかけ ○ https://github.com/rails/rails/pull/39784 ○ 2020年10月にmainにマージされ、Rails 6.1.0としてリリース ○ Rails 6.0.zから6.1.0の間で発生したregressionとも言えます ● #45156 オープン時点でのBug ﬁxes対象はRails 7.0.z ○ Rails 6.1.zがBug ﬁx対象期間、同様の事象の報告はなし ○ Rails 6.1.0からRails 7.0.3まで、この振る舞いとなっていました ● #45256をマージすると、#39784に依存した未知のuntested behavior のregressionを起こす可能性がありました #45256の背景とcloseを選択した理由

Slide 48

Slide 48 text

● Railsのユニットテストを全部見て、アプリケーションに書かれていない振る舞いを探すのは困難です ● (仮にそれができたとしても)その振る舞いのユニットテストのみを追加する pull requestを説得するのも困難です ● フレームワークにその上位のアプリケーションの振る舞いを全てテストするのは不可能だし、適切な方向性ではないと考えています Untested behaviorsへの現実的な対応

Slide 49

Slide 49 text

Railsにnew featureの pull requestを送る

Slide 50

Slide 50 text

よくする質問: “ユースケースはありますか”

Slide 51

Slide 51 text

アドバイス: 最新のRailsを利用することで、実際のユースケース(あなたの使い方)を実装したり、試したりしやすくなるはずです。それを元に説明してみてください古いバージョンのRailsに新機能を追加しても、新しいRailsのコードベースが変わっていて、そのままcherry pickできない可能性が高まります

Slide 52

Slide 52 text

https://speakerdeck.com/yahonda/how-to-get-your-pull-requests-merged

Slide 53

Slide 53 text

あたらしい取り組み

Slide 54

Slide 54 text

https://speakerdeck.com/eileencodes/the-success-of-rails-ensuring-growth-for-the-next-100-years

Slide 55

Slide 55 text

https://rubyonrails.org/2022/6/13/rails-discord-server-is-now-open-to-the-public

Slide 56

Slide 56 text

● Pull requestが自動的にクローズされなくなりました ○ https://github.com/rails/rails/pulls ○ Issueは一定期間変更がないと自動クローズされます ● Contributors情報交換のためにRails Discord Serverができました ○ #contributors チャンネル ● https://discuss.rubyonrails.org も引き続き存在しますあたらしい取り組みの例

Slide 57

Slide 57 text

https://discord.gg/d8N68BCw49 Rails Discord Server

Slide 58

Slide 58 text

● Railsのpull requestに関して質問がある方は: ● Rails / OSS パッチ会 ○ 毎月1回午後5時から午後7時まで、次回は10月25日 ● Asakusa.rb ○ 毎週火曜日午後7時30分から ● 西日暮里.rb ○ 毎月最終月曜日午後8時から、次回は10月31日 Questions?

Slide 59

Slide 59 text

Thank you for attending. Upgrade your Rails today!