こんにちは。今回は、SmartHRのバックエンド開発に欠かせないOSSであるRuby on Railsに初めてコントリビュートしたお話をします。
以前「OSSやっていきの集い」の立ち上げについてお伝えしましたが、それを受けて実際に行ったOSS活動の1つです。
はじまり
とあるプロダクトで、RailsがPostgreSQLの float 型のカラムを正しくダンプできない不具合を発見しました。
t.float ..., limit: 24 で定義したカラムを rake db:schema:dump で db/schema.rb に出力すると、limit のないt.float が出力されてしまいました。
limit がなくなると精度が変わるため、これでは db/schema.rb を期待通り扱うことはできません。
期待しない挙動に思えるということで、rails/railsにIssueを作成しました。
しばらくしても特に返信が付かなかったので、SmartHRのSlackのバックエンドチャンネルにゲストとして入ってくださっているRailsコアチームのkamipoさんに相談しました。
OSSやっていきの集いの題材になる
kamipoさんに相談したところ、どうやらRailsで考慮されていなかった問題のようでした。
一度はkamipoさんに修正をお願いしたのですが、比較的低難易度で対応しやすそうということから、OSSやっていきの集いの題材としてSmartHRで修正させていただくことになりました。
この修正に興味のある人を募集したところ、Railsへのコントリビュート経験がある1名とコントリビュート経験がない2名の合計3名が集まりました。
モブプログラミング形式で時間を取って修正することにし、事前にそれぞれ開発環境を準備して集合しました。
実際の修正とマージまで
集まったメンバーでIssueを確認し、修正に取り組みました。
実際にはこのような流れで修正を行いました。
- まずはIssueの再現コードを手元に持ってきてテストが失敗することを確認
- コード上でスキーマ情報を出力している箇所を特定し、期待する出力のベタ書きをしてテストが成功することを確認
binding.irbを使ってブレークポイントを設定したうえでテストを実行して、処理内容や変数の状態を追いながら修正すべき対象を探索- 最終的に、型の対応付けの初期化で対応元として定義されている
float4とfloat8で対応先が区別されていないことが原因と分かった float4とfloat8の対応先を区別するようにして今回のケースのテストを追加し成功することを確認
ここまでで修正が出来たので、Pull Requestを作成しました。
するとPull Request作成からわずか1時間ほど（！）でkamipoさんにマージしていただき、見事Railsコントリビュートを達成することができました！
マージ後のお話
ここまででお話した修正は、公式サイトの「This Week in Rails」でもヘッドラインで取り上げられ、この記事を書き上げている最中にRails v7.2.2に含まれてリリースされました。
Ruby on Railsという世界中の開発者が使用し、世界中のプロダクトで利用されているOSSにコントリビュートできたことはとても嬉しく誇らしかったです。
まとめと謝辞
以上がプロダクト開発から問題を見つけたところからOSSにコントリビュートできた例でした。
これからもOSSやっていきの集いではこういった活動をしていきたいと思っています！
最後に、kamipoさんにはこの場を借りて心からの感謝をお伝えいたします。IssueのレビューからPull Requestのマージまでサポートしていただきありがとうございました！
We Are Hosting!
SmartHRでは一緒に働く仲間を絶賛募集中です！
今回紹介したように、Railsを始め様々なOSSにコントリビュートするという活動もやっています。
少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！
