Hubotを導入したらレビューの敷居が下がった話

ウチの会社ではHipchatとGitHubを開発のコミュニケーションの中心にしている。
だんだん人も増えてくると、以前よりプルリクの数がそれだけ増えて、レビューで1日終わってしまう人がでてきた。

昔から仕様を知っている人にレビューが投げられがちで集中しやすいとかは他の会社でもよくある話しだと思う。
レビューは自分のタスクと同様に大事だけど、それで自分のタスクが全くできなくなったり、新しく入ってきた人がレビューする機会を失うのはあまりよくない。

というのもあって、Hubotを立ててみてプルリクのレビュアーをランダムで振れるようにしてみた。
Hubotというのはご存知Hipchatのbotとして動くプログラムで、botにコマンドを指定してリモート実行させたり、特定の文字列に反応させたりということがHipchat上でできる。
CoffeeScriptでスクリプト書けるのでとてもお手軽。

sushiという名前のHubotを立てて、GitHubのプルリクのURLをbotに投げるとランダムでレビューお願いします！とメンションを飛ばすようにしてみた。

xxx   | @sushi https://github.com/AAA/BBB/pull/999
sushi | @yyy オナシャス！ https://github.com/AAA/BBB/pull/999

GitHubから流れてくるログから自動でメンションを飛ばさないのは、大きな機能追加などは特定の人にレビューしてもらいたいことがあるので、そこは自分で打つ。assignまで自動でできる美しいんだけどそこまではまだ出来てない。
誰にレビューしてもらおうかなと考える必要もないし、レビューの偏りも結構解消されていい感じになった。
スタートアップはどんどん人が増えるので、新しく入った人にもレビューが振られることで早くプロジェクトになじめるとかそういうのは大きいと思う。

何より、みんなが楽しんでレビューを振れるようになったのがよかった。
pushされたブランチを見て、「俺に来るな、来るなよー・・来たーマジかorz・・」とか振られる側もドキドキできて楽しい。

ランダムレビュー以外にも、みんなの名前打ったりするとその人のおもしろ発言が流れたり楽しい感じになってる。

これまで自分のローカルで動かしてたのでw ちょっと旅行に行ったときは動いてなくて寂しかったと言ってもらえたのは嬉しかった。
普段の開発フローに定着できたので、ちゃんと運用していこうと思う。

方針を決めて守ったり対面のミーティングでなんとかしていけることもあるけど、動く仕組みを作ることで一段上の解決ができることもあるよなーと1つ勉強になりました。

Macの環境構築にhomebrew-cask+Brewfile便利

先週 Macbook Air を新しいマシンにリプレースした際に、環境構築どうしようかなーと思って、homebrew-caskを使ってみたらかなり捗った。

Mac上の環境構築でよく聞くのは、GitHubが公開しているBoxenだと思うけど、PuppetのDSL覚えるの面倒くさいし、パッケージ情報をメンテナンスするのも結構ヘビーだったりする。
対してhomebrew-caskは、Homebrewの仕組みを拡張して、GUIアプリも入れられるようにして、全部brewコマンドで管理できるようにしようぜという思想で作られている。

1つずつコマンド打って全部入れていってもいいんだけど、最近のHomebrewはBrewfileを使ってパッケージ管理できるので一発で入れられて便利。

# Make sure using latest Homebrew
update

# Update already-installed formula
upgrade

# Add Repository
tap phinze/homebrew-cask || true
tap homebrew/binary || true

# Packages for development
install zsh
install git
install vim

# Packages for brew-cask
install brew-cask

# .dmg from brew-cask
cask install google-chrome
cask install virtualbox
cask install vagrant

# Remove outdated versions
cleanup

こんな感じのBrewfileがあるディレクトリで、ターミナルから「brew bundle」と打つと、書いたとおりにソフトウェアがインストールされる。
アップデートも「brew update」でよしなにやってくれる。

BrewfileをGithubかなにかで管理しておけば、新しいマシンが来たときは「brew bundle」を実行するだけだし、新しく環境作り直す場合もbrewコマンドで消すかHomebrewのディレクトリをまるごと削除するだけでいいので簡単。

デフォルトの設定だとインストール先は「/opt/homebrew-cask/Caskroom」になり、「~/Applications」にシンボリックリンクを貼る模様。
これを変えたい場合は、「HOMEBREW_CASK_OPTS」という環境変数に指定すれば変更できる。
自分はhomebrew本体と同様にCaskroomを「/usr/local」下に置きたかったのと、シンボリックリンクは「/Applications」に貼りたかったので変更した。

export HOMEBREW_CASK_OPTS="--appdir=/Applications --caskroom=/usr/local/Caskroom"

ちなみに自分はAlfredをランチャーアプリとして使っていて、homebrew-caskで入れたアプリはシンボリックリンクなので検索対象になってくれなかった。
ただ、対応策としてサブコマンドがちゃんと用意されていて、そいつを実行すると検索対象に含まれるようになった。

$ brew cask alfred
$ brew cask alfred link # CaskroomをAlfredの検索パスに追加

vagrantとknife-soloで開発環境構築を自動化するやつ

最近vagrantとknife-soloで、ってのが流行ってるみたいなのでやってみた。
waka/auto-dev-env

ベースBoxは、vagrantbox.esからUbuntu12.10 server minimalってのを落とせるけど、knife-soloはOmibus Chef Packagingのものをインストールしてくれるのでchefは入ってる必要なかったり、Boxのディスクサイズが10GBと少なかったので、Veeweeを使って作った。
vagrantはポートフォワーディングの設定が簡単で便利ですね。

とにかく、これでムシャクシャしたとき「sudo rm -rf /」がいつでも出来るようになったぞ！

Opscodeのレシピ見ててもRedhat系かDebian系かで動かなくなりそうなもの多いので、もし作ったレシピを配布して開発環境合わせるとかやろうとすると、実行するマシンのOSと仮想環境のディストリビューションを統一するのが大事なんだろうな。