ぺろぺろ - Github pull request bot framework -
名古屋Ruby会議03で発表した。
発表資料
関連記事
原稿
導入
自己紹介
こんにちは、mzpです。
大須はたまにくるので、この大須演芸場も気になってはいたんですが、なかなか入る機会がありませんでした。 まさかこっち側に立つのが最初だとは思っていませんでした。
よろしくお願いします。
会社紹介
仕事では、Misocaという会社でMisocaというWebサービスを作っています。この名古屋Ruby会議のスポンサーでもあるそうです。すごいですね。
Github
会社としてのMisocaはおいといて、サービスとしてのMisocaはGithubのプライベートレポジトリ上で開発を進めています。そのためGithubが開発の中心になります。
プルリクエスト
さらに言えばプルリクエストが中心になります。そのためプルリクエストにまつわるさまざまなルールや運用が生まれます。例えば「コンフリクトに気付いたら声をかけてあげようね」ですとか「githubでコメントしたらSlackでも教えてあげよう」などなどなどです。 最初はこれでもよいのですが、だんだんと面倒になっていきますよね。
bot
そこでbotを作り、こういった運用を自動化しました。
このbotは機能を固定したものでなく、gemによって拡張できるbot frameworkとして作りました。 今日はそのbot frameworkを紹介したいと思います。
使い方
まずは簡単に使い方を話します。
Deploy to heroku
レポジトリに deploy to herokuボタンがあるので、押せばherokuにデプロイできます。
Webhookの設定
あとはGithubでWebhookの設定をすれば動きます。
カスタマイズ
デプロイされたgitレポジトリをcloneしてきてGemfileを更新すれば挙動を拡張できます。 例えば、コンフリクトしているプルリクエストにラベルを自動でつけるようにしたい場合は、Gemfileに gem ‘prpr-conflict_label’ と追記してpushすればOKです。
既存プラグインの紹介
次は各gemでできることを紹介していきます。
prpr-checklist
各プルリクエストに自動でチェックリストを投稿するgemです。
機能を更新したけどヘルプを更新するのを忘れた、とか、バリデーションルールを追加したら既存データと矛盾するようになってしまった、みたいな単純な失敗をしてしまうことありますよね。 そういうときは古来よりチェックリストを使うとよいと言われているので、それです。
チェックリストの内容
チェックリストの内容は、レポジトリ上にあるCHECKLIST.mdという名前のファイルを使うようにしているので、変更も容易ですし、バージョン管理もできます。
余談: これを作ったときにはなかったんですが、今のGithubにはプルリクエスト テンプレートがあるので、そっちつかってもいいかもしれませんね。
prpr-mention_comment
コメント中に「@xxx 」といった文字列が含まれていた場合は、そのままSlackに転送するgemです。
Githubの通知をSlackに流している方も多いと思うんですが、GithubコメントでメンションしてもSlackではメンションにはならないんですよね。 これだとなかなか気づけませんし、気付いてもらえません。
Slackの通知は気付いてくれる人が多いので、これで解決です。
アカウント名の対応
工夫ポイントとしては、Slackのユーザ名とGithubのユーザ名が違う人もいるので、ユーザ名の変換もやっていることです。 これはレポジトリのルートに以下のようなファイルを置くことでカスタマイズできるようになっています。
prpr-gemfile
gemGemfile.lockのdiffを確認して、メジャーバージョンアップとマイナーバージョンアップをしている箇所にコメントをいれるgemです。
定期的にbundle updateをしてプルリクエストを送るbotを飼っているんですが、毎回Gemfile.lockの差分を見ながら「ふむふむこれはbugfixだけだし、いれていいでしょ」「う、こっちはメジャーバージョンがあがってる。ちゃんと調べなきゃ」というのをやるのは面倒なので自動化しています。
prpr-conflict_label
何本もプルリクエストが並行して動いてる状況だと、ちょいちょいコンフリクトが発生します。ただ、Githubのプルリクエスト一覧ではどれがコンフリクトしているかがわからず、個別のプルリクエスト画面をひらいて初めてコンフリクトしていることがわかります。
マージイベントが発生するたびに全プルリクエストを確認し、コンフリクトラベルのつけはずしをするようにしましたgemです。
これで一覧をみるだけでどれがコンフリクトしているかが分かるようになります。
まとめ
以上が、標準的なprprのgemです。 たぶんだいたいのシチュエーションで便利だと思います。 ボクも自分のプライベートプロジェクトで使っていたりします。
Misoca開発フローとの統合
これらとは別にMisocaでの開発フローにあわせて作ったgemもあります。 次はこういったgemについて紹介していきたいと思います。
開発フロー
まずは、我々の開発スタイルについて簡単に説明します。
- 各開発者がプルリクエストを作る。このときはまだWIP(work in progress; 作業中)というラベルをつけておき、まだレビューしなくてもいいよ、ということを明示します。
- プルリクエストが完成したら、レビューを依頼する。 指摘がついたら対応する。
- 最低1人、できれば2人がOKを出したあとでマージする。
- いくつかマージされたプルリクエストがたまってきたらデプロイする。
その他の特徴
補足情報としては、
- レビュー担当者などは特に固定せず、互いにプルリクエストレビューを行なう
- 基本的にはSlackを使ってやりとりする
といった特徴もあります。
prpr-review_label
レビュー依頼部分を支援するgemです。 このgemはREVIEWというラベルがついた場合は、Slackに「レビュー待ちにしました」という通知を流します。
この通知にはラベルをつけた人の名前とアイコンを使うようにしているので、誰が依頼をしたかがすぐ分かるようになっています。
prpr-lgtm
次は「マージする」という部分を支援するgemです。最初は雰囲気でやっていたのですが、
そこで、 * OKの数をラベルとして表現する * 二人がOKをした場合は、プルリクエストにassignされている人にメンションを飛ばす というbotを作りました。
一覧をみるだけで何人がOKをだしているかがわかる、二人がOKを出いた瞬間に気づけるようになり、テンポよくマージしていけるようになりました。
自己
余談ですが、このgemを作る過程でうっかり暴走させてしまい、同僚に大量のメンションを飛してしまい、たいへん申し分けない感じになりました。ごめん。 これは自分のコメントに反応してさらにコメントをつけてしまい、それに反応して…という図です。
prpr-merged
「マージする」という部分を支援するgemはもう一つあります。
「マージする」という行為は影響が大きいので、できるだけみんなに把握しておいてほしいです。 そのため、マージが発生するとslackに通知されるgemを作りました。
もちろんslackのgithub連携機能でも同じ情報は流れてきますが、よりマージを目立たせるという効果があります。
デプロイ
最後はデプロイの支援です。
Misocaのデプロイはチャット経由でできるようになっています。
- チャットで「@bot デプロイしたい」と発言する
- botがデプロイ用の内容をまとめたプルリクエストを作る。 これはマージ先がmasterではなくリリース用ブランチになっています。
- デプロイ用のプルリクエストをマージすると、デプロイプロセスがはじまる
- デプロイされる
という流れです。
このうち、3の「デプロイ用のプルリクエストをマージすると、デプロイプロセスがはじまる」の部分はprprがやっています。
prpr-code_deploy
Misocaのデプロイ作業はAWSのCodedeployを使っています。 codedeployにコミットIDを送ると、デプロイしてくれます。
そこで、デプロイ用のブランチにマージされた場合は、AWS codedeployにそのコミットIDを送り、デプロイプロセスがはじまるようにしています。
まとめ
以上がMisoca開発におけるprprの使い方です。
あとはこのprprを作ったときの話をしていきたいと思います。
先行事例
作るときに参考ににしたものや、あとから見つけたやつなどがあるのでそれを紹介します。
クックパッド
チェックリストの投稿などはクックパッド開発ブログで紹介されています。 ただこれは自分たちで作っていこうな、という趣旨の記事なので、汎用のbotがあるわけではありません。
trailing space bot
Github上で動作するbotというのもいくつかあります。 たとえば、末尾のスペース(trainling space)を検知して修正するプルリクエストを作成するbotもいます。
これはそいつが送ってくるプルリクエストです。
しかしこれは挙動が固定されているため自分たちにあわせて機能を追加・削除していくのは困難です。
拡張可能なbot
プラグインで挙動を拡張できるbotは多数存在しており、開発関係だとhubotやrubotyなどが有名な気がします。
ただこれはチャット経由でなにかする、というものがほとんどで、プルリクエストに反応して何かをするものは見付けれませんでした。
設計
目標
自由に拡張できるgithubのbotフレームワークはないことがわかったので、自分で作ることにしました。 作成時に標榜した目標は以下の通りです。
gemにより挙動を拡張できる。 コア部分と、自分たちの開発を便利にするための機能を切り離す。
botの設定変更は誰でもできるようにする。 これは先ほど紹介したチェックリスト投稿が分かりやすいと思うんですが、チェックリストの内容変更は管理者だけができる、ということになると、チェックリストへの追加作業のハードルがあがってしまいます。そこで、レポジトリ上のファイルが設定ファイルになるようにし、レポジトリにコッミトできる人間なら誰でも設定変更できるようにしました。 設定変更もgitで履歴管理されるようになるのもメリットです。
herokuで動く。 自分でちゃんとデプロイするの大変ですしね。
すばやく作る。 とりあえず日々の運用を楽にするのが先決なので、わりとさっさと作りたかったです。
構成
構成としては以下のようになっています。
- どのイベントに反応するかを決めるHandler
- 挙動を決めるAction
- 環境変数やレポジトリ上のファイルから設定を読み込むsettings
- Slack等に通知するpublisher
といった部分で構成されています。 またイベントを受け取る部分は通常のwebhookの他にテスト用のCLIもあります。
各プラグインがやるのがhandler/actionあたりです。
例: Handler
マージ通知をするgemを例に、もうちょっとだけ具体的に説明します。
マージだけに反応するればいいので、handlerは以下のようになっておりプルリクエストのcloseに反応するようになっています。
例: Action(½)
Actionはこのようになっております。
- 本当にマージされたかどうかの判定
- publisher経由で通知する
例: Action(2/2)
送信するメッセージは、このように環境変数から読むようになっています。
やらなかったこと
prprは最初のバージョンを早めに出して、プルリクエストにまつわる運用を楽にしたかったので、割り切って作った部分もいくつかあります。
WebUIを作らない。 設定画面等をつけようかとも思ったんですが、認証とかを考えると面倒そうだったのと、Webhook受け取るだけでとりあえず動くだろ、ということでWebUIをつけるのはやめました。
Bitbucketのことは忘れる。 最初はGithubとbitbucketの両対応をしようかと思ったんですが、抽象レイヤーを作るのが面倒そうだったのと、bitbucketを使う予定がないので忘れることにしました。
命名
次は名前の話ですね。
コードを書きはじめる前に名前を決める派なので、けっこう初期からこの名前でした。 プルリクエスト=PRに反応するbotつくりたいけどなにがいいかなー?って相談しました。 よくみると夜中の12時くらいに決めてるので、まあそういうことだよなって気持ちになりました。
ヲタクっぽくて気にいっています。
よかったところ
あとは感想です。
- gem化したのでどこでからがプラグインかが明確になって、クラス設計等がしやくなった
- CLIでテストできるようにしたのでデバッグが楽
- 外部のAPIを叩く部分をすべてプラグインにしたので、本体のspecでモックを作るのが簡単だった。
苦労したところ
- githubの新機能(Approve/Project/…)などの機能がなかなかAPIにおりてこない。 ReviewのApproveのAPIがくるまで一ヶ月ほど待ちました。
- PreviewAPIはoctokitにはいってこないので、わりと無理矢理呼ぶことになる。 こんな感じです。
- gemに分割したのでgemspecを書いたり、レポジトリを大量に作るのが面倒だった。
まとめ
まとめます。
