Git で日々の共同作業やリリース作業をサポートする git-daily を作りました

こんにちは。インフラの sotarok です。
先日から Git 関連の話をしている通りですが、社内で Git を使い始めています。
今日は、Git を使った日々の開発〜リリースまでのフローや、そうしたものの運用と、それをサポートするために作ったツール git-daily の紹介をしたいと思います。

ソフトウェア開発とウェブ開発の違い

いやウェブ開発も広義のソフトウェア開発なのですが、ここでいうソフトウェア開発とは、クライアントアプリケーションやライブラリのようなものを指すと思ってください。
実際、ウェブ開発をしている方は感じていることだとは思いますが、両者の開発フローはかなり異なるものです。もちろん社風や開発の方針等によって色々あるとは思いますが、主に次のような特徴が挙げられると思います：

• ソフトウェア開発
  • アプリケーションはクライアントで動作する
  • リリース間隔は比較的長く、次のバージョンまでのロードマップをひきユーザの声の反映・機能追加・バグの修正を行いリリースをする
• ウェブ開発
  • アプリケーションはサーバで動作する
  • リリース間隔が短く、ユーザの声の反映・機能追加やバグの修正等で日々リリースがある

ここで挙げられるものは、必ずその通りではない場合も多いですが、クライアントアプリケーションが毎日のようにリリースされてもアップデートが面倒ですし、ライブラリのようなものが毎日のようにバージョンアップされていては使う方にとってはうんざりです。
一方で、ウェブ開発では、サーバでアプリケーションが動作しているため、デプロイを行うだけですぐにバグ修正等の対応はできますし、スピーディに機能の追加を行えます (いや、もっとも毎日のように仕様変更があったらユーザとしてはうんざりですが、まあそこはまた別の「運営」の話ということで)

両者のリリースサイクルや開発フローにこのような違いがあるのに、同じツールを使っていてはあまりうまくいかないでしょう。

GREE での開発フロー

VCS の利用は、アプリケーションのデプロイや開発フローと密なため、そのチーム・組織での開発フローがどうなっているか、という点も重要になると思います。当然、GREE での Git 導入に関しては、これまで行われてきた開発フローがやりやすいようにツール作りをしました。
以前 開発環境の話 で少し触れたかもしれませんが、GREE では大まかに以下のような流れで開発を行っています。ウェブサービスの開発フローとしては特別珍しいものでもないとは思います。以下の工程が非常に早いサイクルで繰り返されています。

1. 各自の開発環境で開発、VCS を通じて他の開発者と共有
2. リリース出来る状況になったら、staging サーバにデプロイし、最終確認
3. 最終確認が済んだら production にデプロイしてリリース完了

git-flow

先日少し話にだしましたが、弊社でも Git を使い始めた当初、git-flow をリリースフローに使う試みをしていました。この、A successful Git branching mode nvie.com という記事のなかで紹介されている、Branching Model には非常に優れたプラクティスで、このモデル自体は多くの場合に適用できます。
しかし、git-flow というツール自体がすべての開発(特に、これまでその組織でなされてきた開発フローが既にある場合)にバッチリ当てはまるわけではありません。

実際に git-flow を使ってみたいくつかの問題点は、

• リリースサイクルが非常に短いため、リリースにいちいち名前を付けない (and タグは別にいらない)
  • それこそ1日に2度リリースがあることも
• 共同作業がほとんどとなるため、気軽に push/pull やリリース作業の状況に応じた操作をしたい
  • これは先日の gitosis の記事にも通ずる話ですが、日々の作業は基本的に1人で行うものは無く、多人数での開発が前提 (*1)
  • したがって、remote への共有、ブランチのお掃除など、適当にうまいことやってほしい

そんなわけで、こんなツールがあったらいいなーと思うわけです

• 気軽にreleaseブランチを切って気軽にテスト→リリースしたい
• 基本的にすべてのブランチは多人数で共有して開発を進める。気軽にpush, pull、適宜お掃除を行いたい
• releaseブランチ・新しい機能を開発するfeatureブランチ等、新しいブランチを切ったら基本的それは多人数で共有するものだと考える
• Git の自由度を制限して、ある程度決まった形での開発をしたい

というわけで、作りました。

git-daily

git-daily は、その名の通り、毎日の業務やリリース作業をサポートするためのツールです。master-develop ブランチモデルの基本的な概念は、git-flow と同じですが、簡単に説明します。

• master
  • 完成されたソースツリー。これはいつデプロイされても良い。(例えば、新しいサーバを構築したときに、配置して良いソースツリーは、常に master)
• develop
  • 開発中のソースツリー。日々ここにコミットし、push、pullをしてソースを共有する
• release/yyyymmdd-HHMM
  • releaseブランチ。developブランチから切られ、本番サーバデプロイ前の最終確認を行う。
  • リリースの確認作業が終わったら master に merge される。また、ここに直接した修正コミット反映のため、developにも merge される。
  • リリースが終了すると削除される。
• feature/xxx
  • 新機能xxxの開発。featureブランチは、必ず develop に merge してからリリースされる。
  • develop に merge 後削除される。

通常の開発フロー

普段は、develop ブランチで開発し、gitosis と push/pull を行います。develop ブランチに入った変更は、次のリリースに含められる変更だと考えます。

リリースフロー

リリース時は、git daily によって、日付で名前をつけた release ブランチが作成されます。そのソースツリーを staging サーバで最終確認を行います。修正があれば、その release ブランチへ commit, push し、それを再度 staging サーバにデプロイします。
最終確認が終わったら release ブランチを master ブランチと develop ブランチに merge し、最終的に動く master ブランチが完成、その mater を production サーバにデプロイします。

featureブランチを使った開発フロー

feature ブランチを使った開発フローは、以下のようになります。こちらは、基本的に git-flow と変わりありません。ただ、リモートとの共有を前提としています。(*2)

動作環境・インストール

ということで、そんな git-daily というツールを公開しました。
様々な批判をすべて受け流す覚悟で PHP で作られてます。Git のツールを PHP で作るのはどうなんだ、と思いましたが、Mac にデフォルトで入っているものは開発ツールとして使って良いものとします！（←

開発は PHP 5.2.14 上で行いましたが、PHP 5.3.x での動作も確認しています。近いうち Openpear あたりでインストール可能な形にしようと思います。(3)
Git は、1.7 系を利用しています。(4)

• ソース http://github.com/sotarok/git-daily

使い始めるGitリポジトリ上で以下のコマンドを打つことで、初期化します。(オプション入力してもいいし、Enter 押すだけでもOK)

設定を見るには以下のとおり。

リリース作業開始

リリース作業の remote との同期 (remote が設定されている場合)

リリース作業終了

ヘルプも一応。

その他

• あ、そしてしれっとこう説明しちゃいましたが、git-daily ではまだ feature, hotfix 関連のコマンドは対応していないのでした！（ぉ
  • ただし、hotfix 関連については、リリースフローのサイクルが早いため、あまり重要ではない、という見方もあります。このあたりが、git-flow の利用シーンと異なるかな、とも思います。

まとめ

• ウェブアプリっぽい開発スタイル、remote を介した共同開発のを前提としたにあわせた git-daily というツールを作りました
  • ちなみに、git は、PATHの通ったところに git-* という実行ファイルを作れば、それだけで Git のサブコマンド化ができます。簡単ですね。
• やはり Git を色々いじってると、Git の超自由なところを活かしつつ開発スタイルに合わせた Wrapper は必要だなーと感じました。今回のツールは、GREE での開発に適した形に少し汎用的にまとめあげていますが、これが他のところでもバッチリ合うかどうかは別の問題かと思います。特に、Git コマンドを大量に打つのはだるい、と思う人が増えてきたら、自分のチームの開発スタイルに合った形のツールを作ってみると良いと思います。