Git & GitHub & kintone でウルトラハッピー！ - Cybozu Inside Out

６歳と３歳の娘がいる山本泰宇（@ymmt2005）です。こんにちは。

いきなりですが、悔しいです。なにがって、@DQNEO さんが最近書かれた記事「必殺！Github導入に向けて上司を説得する時に使える資料まとめ」に載り損ねてしまったからです。

サイボウズでも Git と GitHub Enterprise を導入しています。導入や運用の助けになる資料やツールを作ったりして、とても便利なのでいずれ公開したいなと思っていたんです。忙しさにかまけて後回しにしていたら、出遅れ企業にグルーピングされてしまうなんて（涙）

出遅れてしまった以上、なにかプラスアルファをお見せするしか名誉挽回の方法はありません。何も失っていないんじゃないかというツッコミはよしてください。こうなったら恥も外聞もなく Subversion 時代の恥ずかしい過去をさらけ出し、もちろん資料も出して、さらにノウハウを詰め込んだツールまで公開します！

というわけでウルトラハッピーな資料です

slideshare.net で見る

ハッピーになれそうですか？資料に書ききれていないことがありますので、記事の残りで補足します。

導入の背景

資料でも書いていますが、Subversion じゃ限界だったんです。 Git かっこいいから導入したい、という理由じゃなくて、Subversion じゃもう無理！だから導入に踏み切りました。

Hazama チームでは cybozu.com のインフラで利用するソフトウェアを開発しています。インフラなので安定性が第一ですが、一方で迅速・柔軟に修正を適用しなければならないことが多々あります。

今はやりの言葉でいうと、継続的にデリバリーしなければいけないんです。これまた、したい、じゃなく、しなければならない。インフラがボトルネックでサービスの改善を遅らせていては、クラウドの価値も半減するってものです。

安定していること
迅速に修正を適用できること

これを実現するには、安定したブランチに、安定した修正を取り込んでいかなくてはいけません。Subversion ではフィーチャーブランチの運用は現実的ではなかったので、コミットひとつひとつを人手で精査していたわけです。

ワークフローについて

よく Git は難しいといいますが、Git というツールそのものはシンプルで美しい作りです。難しいのは、Git には特定の使い方（ワークフロー）というものがない点です。使い方次第でいろいろなことができる反面、使い始める人にとってはいい使い方というものがわからない。

Hazama チームは Git を導入したかったのではなく、安定して継続的にリリースできるワークフローがほしかったので、理想のワークフローを検討することに時間をかけました。A successful Git branching model という有名なワークフローがありますが、継続的にデリバリーするのには向いていないと判断しました。

継続的なデリバリーには、安定ブランチはひとつだけがいいってことです。そんなわけで、試験用と安定版の二つを基本とするワークフローを考案しました。さらに GitHub の PULL リクエストがあまりに便利なので、PULLリクエストを提出してレビューするワークフロー（PULLリクエスト駆動開発）として完成させました。

Hazama tools について

本家 GitHub で公開していますので、お役にたてるようならお使いください。質問や不具合の報告は Issues にどうぞ。

Hazama tools は、上で紹介したワークフローを自動化するものです。GitHub の Issues はしっかりレビューしたり試験をしたりするには機能不足なので、Hazama のチケット管理には kintone を使っています。Git に加えて GitHub を操作したり kintone を操作しないといけないとなると、面倒ですよね。

git push の代わりに git hazama review と打てば、PULLリクエストが自動的に作成されて、kintone に登録され、PULLリクエストからは kintone に自動的にリンクが作成される仕組みとしたことで、手間が減っただけではなく、コミットコメントの書き方や PULL リクエストの出し方を間違うこともなくなっています。