Hubotでこの後めちゃくちゃデプロイした話
背景
僕のチームはGithubを使ってて、HipChatからHubotでHerokuへデプロイさせてる。
Github時代のデプロイ戦略を読んで便利最高と思ったので、僕もプルリクエスト形式のデプロイを本番へ速攻導入した。 何をデプロイするかということが可視化されて、すごいいい。
困ってたこと
プルリクエスト形式のデプロイは便利最高なんだけど、検証環境の分までdeploymentブランチを用意するか悩ましいところだった。 検証環境は作業が同時進行しているため、複数あったほうがよくて、特にHerokuとかを使ってるなら用意しない手はない感じだったりするからだ。
企画への確認はfeatureブランチをそのまま見せたかったりするので、ガンガン検証環境へデプロイしたい。 特にUIの改善だったりってところは出来るだけイメージを共有したいので、早めにレビューするのがいいと思ってて、実装してこの後めちゃくちゃデプロイしたというストーリーが最高だと思う。
そうしたときに、どの検証環境にどのブランチが乗ってるのか分からないので、人間が確認しあう状況に置かれてた。 xxx-edge1ってデプロイしていい?とか会話が発生することになる。 僕は頭悪いので、どこに何がデプロイされてるか全く覚えてられないから、Hubotが覚えてるのがいいと思った。
解決策
terut/hubot-smartdeploy · GitHub というnpmモジュールを作った。
非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 にもあったように、同じブランチは同じ検証環境にデプロイされるのに加え、新しいブランチの場合は以前にデプロイされてから時間がたってる検証環境にデプロイする。 ステータスコマンドで現在の検証環境の状態が確認できる。
無能なのでcapistranoとかには対応してない。 自分で作ってる社内ツールがcapistranoなので、その辺でcapistranoにも対応させたい感じがしてる。
デプロイするといってはいるが、内部はdeploymentsイベントをキックするか、プルリクエストを作って、必要なら自動マージするという実装になっている。 この辺りは atmos/hubot-deploy · GitHub を大いに参考にさせてもらったのだけど、勉強になった。
じゃあ実際、デプロイは誰がやってるんだっていう話だけど、それは atmos/heaven · GitHub のような存在がいて、そいつががんばってる。 hubot-deployとheavenの関係と一緒だ。
雑に作って、チームに導入して、ある程度仕様も固まって来たからテストを書き始めようと思ってるんだけど、jasmine 2.0が最高なんですか? jasmine-nodeが開発鈍いように思えたので、結局mocha + chaiで書き始めようとしてる。 教えてエロい人。