はじめに

 はじめましてoho-sと、お久しぶりですmakki_dです。今日は、metahubというツールの紹介をさせていただきたいと思います。
 
 まず、二人の自己紹介をさせていただきたいと思います。この名前からKLab勉強会No.6を思い出して頂いた方、ありがとうございます。そこで発表した三人のうちの二人です。二人とも、KLab開発部内で新設されたEngineering Managerという役職についています。社内ではEro Managerなどとも言われる略してEMが、どのようなミッションについているかと言いますと、社内の開発・技術的な課題などを横断的にエンジニア視点でマネジメントし、問題解決やビジネス価値の向上を目指す役職です。まぁ、簡単にいえば何でも屋ですね。そんな二人が、社内のある課題の解決のために作ったのが、metahubです。

top


metahubとは何か?  metahubは、githubのリポジトリを登録すると、定期的にクロールしてPullRequestを取得し、そのPullRequestをフィルタリング・タグ付けして一覧表示するサービスです。


背景・課題

 最近、社内案件のリポジトリとして、githubのプライベートリポジトリを使う案件が増えてきました。開発部全体でもgithub移行を後押しし、今後github Enterpriseも視野に入れた、バージョン管理戦略を考えています。

 一方で、弊社のモバイルオンラインゲーム案件の数は、どんどん増え、コードベースが似ているものの、各案件の事情を反映した、「類似」の案件が「多数」「別々のプロジェクトグループ」によって開発・運用されています。これにより、ある案件で判明し修正した問題点を、他の案件がまた作りこんでしまい、問題を起こしてしまうなどの、課題が出てきています。

 githubでは、Pull Requestなどの仕組みを用いることで、社内でソーシャル開発ができ、またgithubという一箇所にリポジトリを集約することも出来て、上記の課題を解決していけそうに見えたのですが、残念ながら運営されている「多数」の案件に対して、横断的に十分な人数のレビュアーがつけない状況になっています。

 ここで問題になるのは、リポジトリを集約できたとしても、結局レビューすべき量は変わらないということです。一箇所に集約できて、ワンストップでレビューできる(かつレビューの仕組みがシステムに組み込まれている)のはとても有効なので、もう一手考えましょう!ということで、二人で考え、見なければいけないPull Requestを様々な条件でフィルタリングして絞り、さらに集約することで、レビューするコードの量を減らし、効率化する仕組みを作ったらどうだろうと、実装したのがmetahubです。


やったこと

 metahubという名前は「高次な」という意味のmetaをgithubのhubと組み合わせたものです。仕組みとして、githubAPIを用いてmetahubに監視対象として登録した案件のリポジトリから、Pull Requestを定期的に取得し、含まれるDiffから、Filterに適合すものを見つけてタグ付けするものです。タグ付けした結果は、githubのPull Requestへのリンクとともに表示され、気になるPull Requestを見つけたら直接ジャンプすることができます。

pullrequest1

 フィルタとしてどのような条件があるといいだろうということで、議論は白熱しました。つまり、良くないコードや、障害につながるコードってどういうコードだろうということです。

 トランザクションやロックが関わるところは、十分に検証しなければならないよね、ということで、FOR UPDATEやbeginTransaction、commit、rollbackといった文字列を検出するフィルタを作りました。経験上、複合主キーがあるテーブルは設計が甘いことが多く問題が起こりやすかったので、検出する正規表現フィルタを作成しました。フレームワークのコアに近いところのコード変更をしている箇所もレビューは必要でしょうということで、フレームワークディレクトリへの変更も検出できるフィルタを作成しました。実は、コミットした人も見えたらいいんじゃない?ということでそんなフィルタもあります。ある人のコミットだったら反応するものですね。幸いなことに、まだこのフィルタを本格的に使うような、常に問題のあるコードを書くような人は、社内にはいません。他にも、よくあるTypoであるとか、コマンド実行しているところの抽出などのフィルタを作成しています。

filter

 実際に作ってみて、現在社内で動かしているのですが、登録されているすべての案件のPull Requestが集約されるため、非常に横断的に見やすくなっています。特に、合致した条件がファイル名とともにわかりやすく表示されるので、レビューするべき点がわかりやすくなります。また、実際に複合主キーに関してのプログラムミスや誤ってコミットされた一時ファイルなどがmetahubで検出出来ました。

pullrequest3

 metahubのコードは(github  https://github.com/KLab/metahub)で公開しています。


今後の展開

 metahubは、こんなツールがあれば便利じゃないかということで作ったのですが、作ったあとに障害管理フローに組み込んだらもっと有益なんじゃないということに思い至りました。つまり、障害が起こった時に、原因コード(コードが原因だった時に)の特徴から、類似のコードなどを検出するフィルタをmetaubにフィードバックすることで、障害管理のPDCAサイクルを有効に回すことができるのではないかということです。類似のコードがコミットされた時に自動的に抽出して、レビュアーにタグ付けして提示できるのです。

 これまで、小規模で類似した多数の案件を、ある程度独立した多数のチームで並行して開発している大規模な組織での開発管理の方法論が、あまり議論されていないのではないでしょうか。metahubは、githubなどの便利で素晴らしいツールを、よりうまく組織に合わせて使いながらの、上記の課題に対しての私達のアプローチの一つです。是非、社内からも社外からも、様々なご意見を頂きたいと思います。