先日、ひょんなことから人生初の OSS 貢献を果たしました。
色々試行錯誤しながら取り組み、学ぶことが多くありました。貴重な経験ができたと思うので、体験記としてまとめます。
僕のように、初めて OSS 貢献を始めようと思っている方の参考になれば幸いです。
作成した Pull Request
ビデオ会議サービスの Zoom の API が V1 -> V2 にバージョンアップすることに伴い、Zoom の Ruby クライアントのメソッドを修正した Pull Request です。
背景
- 2018/11/1 で Zoom API V1 が depreciated になり、Zoom API V2 の利用がメインになる
- 社内で開発している Web アプリで、Zoom API クライアント の gem であるzoomus を使っていた
- しかし zoomus が V1 の対応しかしておらず、Issue はあるが対応メドはたっていない状況だった
- depreciated まであと約1ヶ月。割と詰んでいる、どうしよう。。
対応方針検討
最初は zoomus 自体に修正は入れず、Web アプリ側で、zoomus のメソッドをオーバーライドして対応できないかと考えていました。
そんな中会社の先輩 @aki77 さんから、「別のプロジェクトでも同様に zoomus を使ってるので、直接 PR 送ればいいのでは？」というアドバイスが。
とはいえ、zoomus は V1 の対応のみ。API エンドポイントや認証方法の修正なども対応範囲が広く、大変そうでした。
どうすればよいかあれこれ調べていたところ、会社の先輩 @mat_aki さんからの助け舟が。
zoomus の fork リポジトリ群から、API V2 の対応を進めていそうなリポジトリを見つけてくださいました…！
コミットログも活発で、ガンガン更新していそうな感じ。
また gem もリリースしているようでした。これは有力。
こちらを使えると、利用しているメソッド修正のみの対応に範囲が絞られ、見通しが立ちそうです。このリポジトリを fork して、今回の Web アプリで利用するメソッドを書き換える対応を進めていきました。
Pull Request を送るまで
こちらを参考に PR 作成を進めました。
GitHub Help にCreating a pull request from a fork というガイドがあるので、こちらも参考になります。
fork して Pull Request を送るのも初めての経験でした。。
1. Fork it
まずリポジトリを fork します。fork してできたリポジトリは以下の通り。
2. Create your feature branch
ローカルにリポジトリを clone し、開発ブランチを作成します。
$ git clone https://github.com/SonicGarden/zoom_rb
$ cd zoom_rb
$ git checkout -b my-new-feature
3. Commit your changes
ここからは修正対応を進めていきました。簡単に対応について書いていきます。
依存 gem インストール
今回は gem の開発なので、依存している gem をインストールします。
$ bundle
テスト実行
gem で準備されているテストを実行し、テストがすべて通ることを確認します。今回は特に修正の必要はありませんでした。
$ bundle exec rspec
開発開始
Zoom API ドキュメントをそれぞれのバージョンで確認して、レスポンスの違いを確認しながら修正を進めました。
社内アプリで利用しているのは user_create と meeting_create というメソッド。それぞれ以下のような差分がありました。
| メソッド | API V1 | API V2 |
|---|---|---|
user_create |
作成オプションが create のみ |
作成オプションが create,custCreate, autoCreate, ssoCreateの4パターンに |
meeting_create |
URLが/meeting/create
|
URLが/users/{userId}/meetings
|
リクエストパラメータは Zoom API の Playground を参考に確認しました。
修正はこんな形で。URLや、パラメータの渡し方を修正する感じです。
修正ができたら、実際にローカルのコンソールで API 実行できるか確認し、
$ bundle exec irb
関連する spec も追加し、All Green になることを確認しました。
4.Push to the branch
開発が完了したら リモートリポジトリにプッシュします。社内ではこの時点で、fork したブランチを基に、社内の Web アプリを先に修正して使えるようにしました。これも fork の利点だなと思います。
$ git push origin my-new-feature
あとは Pull Request を作成し、マージされるのを待つのみ…！
5. Create new Pull Request
いよいよ Pull Request を作成します。
fork 先で Pull Request を作成すると、fork 元の master ブランチが base になった状態で差分確認画面に移ります。便利ですね…！
慣れない英文、初めての OSS への PR だったので、社内の人に書いた description を確認してもらってから出しました。できる限り丁寧に書いたつもりです。
関連して、CI が spec と関係ないところで失敗していたので、併せてコメントを残しておきました。
待望のコメント
そして PR を出してから 20日ほど経ち、ついに PR にコメントが来ました！
概ね OK だけど、 Hash の Key と Value を入れ替えてくれ、というリクエストでした。
Public Beta 版のSuggested Change 機能を使ってコメントくださいました。見やすい…！
そしてマージへ
修正完了の連絡後、ついにマージされました！！
gem のバージョンも上げてくださりました。このときの達成感は尋常ではありませんでした…！
今回の OSS 貢献を通して学んだこと
- Pull Request を出すという目的を持つと、必然的にコードを理解しようとして読むようになる
- 仕事で使っているライブラリを修正する必要が出てきたときは、まず fork して修正して使える状態にしておき、本家リポジトリに PR を出しておくと良い
- fork 先に必要な修正をしているリポジトリがあるかもしれない
- 海外のプログラマと直接英語でやり取りするのは非常に刺激的。日本にいても英語を使ういい機会になる
- 今回は偶然 API クライアントの修正だったが、分量的にも、API クライアントはとっかかりとしては良い題材だと思う
- 修正していて気づいたことは Pull Request にコメントを入れておくと、メンテナーが対応してくれるかも
おわりに
今回の OSS 貢献を通して、OSS 貢献の魅力を体感することができました。これからも OSS 貢献できたら記事にまとめようと思います！