プログラマの思索

分散バージョン管理Git、Mercurialを絡めたチケット駆動開発で、興味深い事例があったのでメモ。

【事例1】
gitだからこそできるチケット駆動開発のやり方 - kunitの日記

今やっている方法は、作業するなら作業用のブランチを切れ！それにはチケット番号を付けろ！という方式にしている。
たとえば会員管理の機能に追加したい場合は以下のような手順になる。
1. 会員管理を拡張したいなぁ
2. じゃRedmineでチケットを切るぞ
3. チケット番号が振られた(たとえば #567 だとする)
4. さぁ、ブランチ切るか(members_567)
5. そのブランチで作業開始！
濱野さんがWEB+DBでも入門Gitでもかかれている「トピックブランチ」というものの良さが本当に現れてくる。

【事例2】
Mercurialを使った俺々バージョン管理ノウハウまとめ(2009年夏編) - 文殊堂

ticket毎に開発作業用branchを作成する
* 同期branchから作成する
* 同期branchから随時rebaseする
* 必ず、同期branchの最新版からrebaseした状態でテストを行う。
* テストが通ったらticket別branchから同期branchにmergeする。その後、同期branchの内容で中央リポジトリにcommitする。
o 同期branchにmerge後、ticket別branchはinactiveなbranchになる

いずれの事例も、作業する時はチケットを作り、trunkから切ったブランチにチケットNoを紐づけて運用する。
つまり、チケット単位にブランチを作り、そのブランチ上でソースの修正を行い、作業が完了したらtrunkにマージしてチケットが終了する。

分散バージョン管理では、ブランチは中央リポジトリではなく、開発者個人のローカルなリポジトリに作られる。
つまり、SVNやCVSのような中央集権的バージョン管理ではローカルの開発環境で作業していたコードラインを、GitやMercurialのような分散バージョン管理では、明示的に開発者のローカル環境のブランチとして作業できる。
その利点は、trunkとは別個に作業履歴を残せること、そして、分散バージョン管理の優れた自動マージ機能のおかげで、trunkにすぐに反映できることだ。

そして、このブランチをチケットに紐付けて、作業ステータスを管理できるようにする。
このやり方をトピックブランチと呼ぶらしい。

SVNなら管理しづらいブランチも、分散バージョン管理では普通の状況であり、その利点をフルに生かしている。
しかも、チケット駆動開発と絡めれば、トピックブランチの作業状態もBTS上でリアルタイムに把握できる。

このトピックブランチは、プライベートブランチ、タスクブランチの一種とも言えるが、チケット駆動開発とかなり相性がよい。
トピックブランチをチケットブランチと言ってもいいくらいだ。

特に、作業者が複数人の場合、更には大規模プロジェクトで並行開発する場合、あるいは、組込製品やパッケージ製品での並行開発で、このやり方は大きな威力を発揮するのではないか？

アジャイル開発が事実上、並行開発せざるを得ないように、チケット駆動開発はソフトウェア構成管理と密接に関係する。
その理由は、チケット駆動開発と並行開発の相性が良いから。

元々、Redmineでは、1リポジトリ＝1プロジェクトの運用思想のため、ブランチ単位にRedmineプロジェクトを作る。
この複数プロジェクト機能を使えば、チケット駆動開発を並行開発のインフラにできる。

普通は、並行する2本のライン(trunk, branch)はプロジェクト単位だが、上記のトピックブランチはチケット単位でブランチを管理する。
つまり、BTSのプロジェクトとチケットで観点を変えて、ブランチを管理すればいい。

分散バージョン管理とチケット駆動開発の組み合わせは、並行開発の管理を劇的に効率化する可能性があると思う。