Hello hubot

Hubotを導入して半年たったのでレビューします。

Hubotとはなにか

いわゆるボットです。サーバー上で待機していて、こちらからコマンドを与えたりイベントが発生するとそれに応じて処理をしてくれるプログラムです。

module.exports = (robot) ->
  robot.respond /PING$/i, (msg) ->
    msg.send "PONG"

下記のような特徴を持っています。

1. CoffeeScriptで「どういうメッセージがきたら　なにをする」というパターンをサクサク追加できる。
2. 機能拡張のスクリプトを簡単に使い回せる。(hubot-scriptsレポジトリで公開されている)
3. Campfire, IRC, Skype, Yammerの様々なコミュニケーションツール、HTTP等をインターフェイスとして使える。

特に重要なのは3つ目で、デプロイのコマンドはIRC経由で受け取る、クラッシュレポートはHTTP経由で受け取ってから必要な人にSkypeで通知する、というようなことを一役でこなすことができます。

なにができるのか

• Skypeからテスト用アプリのビルドデプロイ、リリース用パッケージの準備等を指示できる。
• プルリクエストが作られたときやアプリのクラッシュが検知された時に、必要な人に通知できる。コミュニケーションのストレスが大分減る！
• うまく活用してJenkinsの渋滞を解消できる。

Hubotのインストール

Hubotはnpmモジュールとして提供されています。

npm install -g hubot coffee-script

自分用のボットの作成

Hubot単体ではほとんどなにもボットとしての活躍はできないので、基本的にはHubot createコマンドを使って自分用のHubotコピーを作り、そこのscriptsディレクトリに自前のスクリプトを追加していく形で使います。

hubot --create mybot

mybotディレクトリができるので、その中にある./bin/hubotを実行するとデバッグ用に起動できます。

cd mybot
./bin/hubot

2013年7月10日現在、Hubot ver.2.5.5で上記コマンドを試すと「’ntwitter’モジュールが見つからない」というエラーが発生しています。その場合、hubot-scripts.jsonから”tweet.coffee”を削除することでエラーを回避できます。 参考: Error: Cannot find module ‘ntwitter’ Issue #527 github/hubot
Hubotはデータの保全にRedisを使うのでRedisが入っていない状況では警告がでます。brew等でredisもインストール・起動しておきましょう。

アダプター

前述の通り、HubotはインターフェイスとしてIRCやSkype等様々なツールを利用できる。各ツール経由でHubotにアクセスするためにはアダプターと呼ばれるライブラリをインストールする必要がありますが、アダプターの設定方法はツール・サービスによって様々なのでここでは省略します。
Hubot Adapters
また、アダプターをインストールしていない状況でも./bin/hubotで起動したプロセス上での直接のコマンド入力、HTTP経由でのコマンド入力が可能です。
./bin.hubot上で試しにhubot pingとうってみるとPONGが返ってくるのが確認できます。

Hubot> hubot ping
Hubot> PONG
Hubot>

スクリプト

hubot上での処理は全てscriptsディレクトリの下にcoffeeファイルで定義します。例えばこのPING / PONGは、scripts/ping.coffeeに書かれています。

module.exports = (robot) ->
  robot.respond /PING$/i, (msg) ->
    msg.send "PONG"

パターン定義には正規表現を使うことができ、通常のJavaScript/CoffeeScript同様、マッチした内容を取得できます。

  robot.respond /ECHO (.*)$/i, (msg) ->
    msg.send msg.match[1]

scripts/httpd.coffeeにはIRCやSkype経由ではなく、HTTPリクエストでコマンドを受け付けるサンプルが定義されています。

module.exports = (robot) ->
  robot.router.get "/hubot/version", (req, res) ->
    res.end robot.version

独自の処理を追加したい場合は、scriptsディレクトリの下に同じようにcoffeeファイルを追加していけばOKです。パターンの定義自体は極めてシンプルなので、scriptsディレクトリにあるサンプルやhubot-scriptsレポジトリ内のスクリプトを見れば大抵のことはわかると思います。

Hubotの利用場面

というわけで、Hubot自体は「設定されたパターンに該当されたコマンドを受け取ったら、該当する処理を実行する」だけのシンプルなプログラムです。同じようなことはJenkinsをはじめとするCIツールでもできそうです。
実際のところ、Hubotがないと絶対実現できないことは多くありません。ではなぜHubotを使うのかというと、

1. 実行毎に手動でパラメータを指定したいような処理は、Jenkinsに比べて実行させやすい。(ビルドのアップロードで一言説明メッセージを添えたい場合、等)
2. なんでもかんでもJenkinsを起点にするとJenkinsで渋滞が発生するようになるので、負荷分散できる。
3. タスクの内容によってはJenkinsよりも設定がシンプルで楽(通知の中継・分配等)

という理由があるためです。つまり、JenkinsをはじめとするCIツールが苦手な部分を補うという点でHubotが活躍します。
細かい設定が必要なタスクは、HubotのCoffeeScriptを書くよりもJenkinsのジョブの設定を行った方が圧倒的に管理しやすいので、HubotをJenkinsのジョブ実行のためのインターフェイスとして使うのも効果的です。
また、Jenkinsのタスクはキューに積まれていって順番に処理されていくため、一つ一つのタスク自体が短い時間で終わる場合でも、渋滞が発生するとイベントが発生してから処理されるまでのタイムラグがひどくなってしまいます。なので、通知系の短い時間で処理でき、かつリアルタイム性が求められる処理はJenkinsよりもHubotを使う方が効果的です。

具体的に?

最後に、具体的なHubotの活用例をご紹介します。

• リリースのタイミングをSkype経由で指示する。簡単なリリースノートを引数として渡す。hubotはコマンドを解析したら、Jenkinsのリリース用のジョブを走らせる。
• アプリケーションがクラッシュしたら、Crashlyticsからの通知をHTTP経由で受け取る。そして、関連チームのメンバーにSkypeで通知する。
• GitHubでプルリクエストが作成されたら、通知をHTTP経由で受け取る。作成したメンバー以外のメンバーにSkypeで通知する。これ便利。

おまけ

HubotはSkypeからのコマンド入力に対応しており、スマートフォンのSkypeでは音声入力が可能です。つまり、音声入力によってアプリをリリース、みたいな未来がそこにはあります。
 
 
ただし音声入力は固有名詞に弱いので、大抵失敗します。