Ruby
GitHub
初心者
OpenSource
OSS

OSS 貢献体験記 - ビデオ会議サービス Zoom API バージョンアップに伴う Ruby API クライアントのメソッド修正

先日、ひょんなことから人生初の OSS 貢献を果たしました。

色々試行錯誤しながら取り組み、学ぶことが多くありました。貴重な経験ができたと思うので、体験記としてまとめます。

僕のように、初めて OSS 貢献を始めようと思っている方の参考になれば幸いです。

作成した Pull Request

Update user_create action changeable and update meeting_create endpoint by gotchane · Pull Request #2 · hintmedia/zoom_rb · GitHub

ビデオ会議サービスの 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 さんからの助け舟が。

zoomusfork リポジトリ群から、API V2 の対応を進めていそうなリポジトリを見つけてくださいました…!

https://github.com/hintmedia/zoom_rb

コミットログも活発で、ガンガン更新していそうな感じ。

image.png

また gem もリリースしているようでした。これは有力。

https://rubygems.org/gems/zoom_rb

こちらを使えると、利用しているメソッド修正のみの対応に範囲が絞られ、見通しが立ちそうです。このリポジトリを fork して、今回の Web アプリで利用するメソッドを書き換える対応を進めていきました。

Pull Request を送るまで

こちらを参考に PR 作成を進めました。

https://github.com/hintmedia/zoom_rb#contributing

GitHub Help にCreating a pull request from a fork というガイドがあるので、こちらも参考になります。

fork して Pull Request を送るのも初めての経験でした。。

1. Fork it

まずリポジトリを fork します。fork してできたリポジトリは以下の通り。

https://github.com/SonicGarden/zoom_rb

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_createmeeting_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 を参考に確認しました。

https://developer.zoom.us/playground/

修正はこんな形で。URLや、パラメータの渡し方を修正する感じです。

image.png

修正ができたら、実際にローカルのコンソールで API 実行できるか確認し、

$ bundle exec irb

関連する spec も追加し、All Green になることを確認しました。

image.png

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 になった状態で差分確認画面に移ります。便利ですね…!

image.png

慣れない英文、初めての OSS への PR だったので、社内の人に書いた description を確認してもらってから出しました。できる限り丁寧に書いたつもりです。

image.png

関連して、CI が spec と関係ないところで失敗していたので、併せてコメントを残しておきました。

image.png

待望のコメント

そして PR を出してから 20日ほど経ち、ついに PR にコメントが来ました!

image.png

概ね OK だけど、 Hash の Key と Value を入れ替えてくれ、というリクエストでした。

Public Beta 版のSuggested Change 機能を使ってコメントくださいました。見やすい…!

image.png

そしてマージへ

修正完了の連絡後、ついにマージされました!!
gem のバージョンも上げてくださりました。このときの達成感は尋常ではありませんでした…!

image.png

今回の OSS 貢献を通して学んだこと

  • Pull Request を出すという目的を持つと、必然的にコードを理解しようとして読むようになる
  • 仕事で使っているライブラリを修正する必要が出てきたときは、まず fork して修正して使える状態にしておき、本家リポジトリに PR を出しておくと良い
  • fork 先に必要な修正をしているリポジトリがあるかもしれない
  • 海外のプログラマと直接英語でやり取りするのは非常に刺激的。日本にいても英語を使ういい機会になる
  • 今回は偶然 API クライアントの修正だったが、分量的にも、API クライアントはとっかかりとしては良い題材だと思う
  • 修正していて気づいたことは Pull Request にコメントを入れておくと、メンテナーが対応してくれるかも

おわりに

今回の OSS 貢献を通して、OSS 貢献の魅力を体感することができました。これからも OSS 貢献できたら記事にまとめようと思います!